ok, so the easier way to run Jenkins, two methods:
- if you download the
jenkins.warfile, you can just runjava -jar jenkins.warfrom the command line - otherwise, you can run it from docker using:
docker run -p 8080:8080 -p 50000:50000 -d jenkins/jenkinsor something like that (just replace the blueocean image name withjenkins/jenkinsinstead; that’s the up to date image)
then you can run
docker logs … with the container id to see the startup log which prints out the admin password
otherwise, you can use
docker exec container_id cat /path/to/passwordFile.txt (the /var/jenkins_home one)
for WEBSITE-669, I think you’d be fine submitting a PR with what you think is best. by including screenshots in the PR description, that will likely help get quicker feedback
if you use the
java -jar method of executing Jenkins (it comes with Jetty embedded so you can run it standalone without installing it into your own Jetty/Tomcat/other Java servlet container), you’ll have the simplest time finding the logs and files inside jenkins home compared to docker. Jenkins is developed by people working in Windows, Mac, and Linux (possibly BSD, too), so you shouldn’t have much trouble developing and running Jenkins natively. the Jenkins website, on the other hand, does not seem to be portable :(
let me know if you have any other questions!
well, that depends on what you’re using it for. for development purposes, it’s usually easier to use it directly in ubuntu (not as the apt package, though; that’s probably outdated). when running in production, you might want to use docker, but at that point, you’re likely better off going full kubernetes
if you were developing a feature for a docker plugin or perhaps needed to write integration tests that use multiple docker containers, then using docker would make a lot of sense. you can usually get away without using docker, though, in development (and in production, too; Jenkins is older than Docker :P)
on the other hand, if you’re already in Linux, then using Docker is just as fast as native, so that’d be up to you. since I’m on a Mac, I usually just develop without docker
I am, however, relying on some docker images to develop this other thing I’m working on, so again, the choice is more so up to you with whichever you’re more comfortable using
now if you end up running an instance of github enterprise, for example, then you might want to use docker, though that’s just to make it easier to install everything on the same computer
Though assuming that the GitHub Apps API is the same on both GitHub.com and GHEnterprise, we might not need to touch that
Oh no that’s not good. Hmm. My coworker developed some feature recently related to that to allow hosting static contents on a separate domain in order to allow for less strict CSP settings. Can you do it as a regular CSS file? Though then we’d need to figure out the proper URL to it
in fact, most security features have system properties available to disable them since most of them were added later on in Jenkins, and who knows what people use it for sometimes lol
@yamhai found the docs about it: https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy
I suppose you could change the CSP to allow inline css, right?
that would probably be easier than figuring out how to get the correct include URL from a plugin file
and today is the day that I get to work on the docker docs. I hope to make them more secure as well as simpler to set up via
docker-compose which is relatively easy to generalize from for more complex setups (or just use the helm chart for Jenkins; there’s like hundreds of them lol)
@urwa I just noticed that this repo has better docker instructions by the way: https://github.com/jenkinsci/docker
Damn let me type it again
At work, we don’t typically plan a project timeline that far out in advance compared to Outreachy since things change so much. What I’d suggest is to break down the GitHub Apps feature into tasks and spread them over the three months. Leave time to do a couple demos, blog posts, and maybe a little extra time in case anything takes longer than expected. Feel free to send me your draft plan if you’d like some feedback before saving it in your application
About the project timeline, I left it empty. But let me quickly work on a tentative plan if its a compulsory question and get some feedback from you if I can squeeze it in the timeline.
https://issues.jenkins-ci.org/browse/JENKINS-55719 or maybe not this one
this filter might help you find things: https://issues.jenkins-ci.org/browse/JENKINS-59785?jql=statusCategory%20%3D%20%22To%20Do%22%20AND%20type%20%3D%20Bug%20%20%20AND%20project%20%3D%20JENKINS%20AND%20component%20in%20(git-client-plugin%2C%20github%2C%20github-api-plugin%2C%20github-branch-source-plugin%2C%20github-oauth-plugin%2C%20github-plugin%2C%20git-plugin)
Hi Matt,
I tried looking into this issue you mentioned https://issues.jenkins-ci.org/browse/JENKINS-55719
I assume this is related to jenkins git plugin. As a starting point, I tried a couple of tutorials to integrate jenkins with github, so that pull and push requests trigger build on jenkins.
I have been able to make it work.
I set up the webhook on one of github projects. Set up jenkins with SCM as github repo link. I exposed my local server to web using ngrok.
When I commit code and push it to my remote server. I get the following error.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 403 No valid crumb was included in the request</title>
</head>
<body><h2>HTTP ERROR 403</h2>
<p>Problem accessing /job/demoPipeline/. Reason:
<pre> No valid crumb was included in the request</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.z-SNAPSHOT</a><hr/>
</body>
</html>I have looked up a couple of solutions online but could not resolve it.
I have been hopping around on tutorials and not finding one single detailed guide to make it all work.
Can you please guide me to the right direction so I can get the basics down.
Hi @jvz , I looked into 59139 issue. I've submitted a PR here: jenkinsci/git-client-plugin#476. While this works, I'm not sure what Florian meant by "GitLFSPull should be changed to simply flip a boolean in CliGitAPIImpl." Where can I change GitLFSPull call?
