I've used the Simple Promote Plugin in Jenkins and it set my build to "keep this build forever".
Is there any way I can delete it?
I got access to the slave who build it and to the master (tried to find anything related in there but no luck).
I'm not sure whether (or how) the Simple Promote Plugin affects this at all, but can't you just click the button that says "Don't keep this build forever", followed by "Delete"?
When a build is marked as "keep forever" (and the padlock icon shows next to the build), you should be able to "unlock" it by pressing that "Don't keep..." button on the build page.
Just as Christopher said, you can remove the build just by deleting the build directory on the master, inside the job directory.
However if you access the page again, the build data gets dumped to disk again. So you either shut down Hudson first, or you go to the Hudson management console and 'Reload Configuration from Disk' which basically discards whatever's in memory and reloads from your config files.
Just make sure you do it right after deleting the folder.
In order to delete builds marked "keep this forever" you should change that flag to opposite state.
Please follow next steps
Open within a text editor $HUDSON_HOME/jobs/job-name/builds/xx/build.xml
Change
<keepLog>true</keepLog> to <keepLog>false</keepLog>
Go to Manage Jenkins -> Reload Configuration from Disk
After these steps you will be able to delete build marked as "keep this forever"
I think that the final (and may be the only one step) to completely delete build from Hudson's history is to modify "nextBuildNumber" file placed in job directory.
Please remember that "Don't keep this build forever" button will only appear when you enable "Discard Old Builds" inside job configuration. I am not sure if it affects Simple Promote Plugin, but it work in this way with 'Release Plugin'.
MichalT
Not sure about masters and slaves, but there is an answer here that allowed me to delete a build "explicitly marked to be kept".
List all keep-forever builds in Jenkins?
Related
I am new user to jenkins. My jenkins version is 1.594. When we got the confirmation from jenkins team about onboarding the jenkin job, i did not find the build now option for the job.
I just bumped into the same problem, but none of the mentioned solutions worked. I had created a new job using the Copy from functionality. I was then sent to the job configuration page. I left this page without pressing Save or Apply, and the Build now link did not appear. I then went back to the configuration page, pressed Save, and the Build with parameters link became visible.
Add one more possible answer:
Under some circumstances, you may automatically logout and stay at the same page(no button available), try login again fixed my problem...
Build now option does not come in either of the below reasons:
Project might be disabled. Please enable it or ask the concerned team to enable it.
You do not have enough permission to build the project. Please raise the concerned permission.
You can choose "This build is parameterized" in configure and add a dummy Boolean parameter, check default value.
Then you will get a build button
Another reason why "build now" might not appear is if your Jenkins couldn't find your Jenkinsfile. Scan your project and check the log.
If you find a line that says 'Jenkinsfile' not found, then that's your problem. Check the git repo and make sure the file is there and make sure there isn't a typo in the name.
In my case, I had accidentally hit the red X on Behaviors (under Branch Sources with a multi-branch pipeline). The default behavior "Discover branches" should be there. You can put it back by choosing the Add option below.
I've used jenkins for quite a few years but have never set it up myself which I did at my new job. There are a couple questions and issues that I ran into.
Default workspace location - It seems like the latest Jenkins has the default workspace in Jenkins\jobs[projectName]\workspace and is overwritten (or wiped if selected) for every build. I thought that it should instead be in Jenkins\jobs[projectName]\builds[build_id]\ so that it would be able to store the workspace state for every build for future reference?
Displaying workspace on the project>Build_ID page - This goes along with the previous as I expected each 'workspace' for previous builds to show here. Currently in my setup this individual page gives you nothing except the Git revision and what repo changes triggered the build. As well as console output. Where are the artifacts? Where is the link to this build's workspace that was used?
Archiving Artifacts in builds - When choosing artifacts, the filter doesn't seem to work. My build creates a filestructure with the artifacts in it inside workspace. I want to store this and the artifacts filter says it starts at workspace. So I put in 'artifacts' and nothing gets stores (also where would this get stored?). I have also tried '/artifacts' and 'artifacts/*'.
Any help would be great! Thanks!
It does seem like you are confused about several aspects of Jenkins.. I think your question basically boils down to the following.
What is a difference between a workspace and a build?
So, here are some thoughts on this topic:
Builds are historical data. They (usually) don't change like a workspace does during building/checkout.
Builds contain information about a run (e.g. its status, build number, change log, etc) and any artifacts that you tell it to archive (logs, test results, etc). They (usually) don't contain source code like a workspace.
Builds are stored in the Jenkins\jobs\[projectName]\builds\[build_id]\ directory. This is a directory managed by Jenkins and you (usually) do not need to modify anything in this directory. However, workspaces are directories meant for the build and you can do pretty much anything with them and place them anywhere (it does not need to be in the default Jenkins\jobs\[projectName]\workspace directory.
Workspaces should be able to be wiped at any given time. To restore it, just rebuild the job with the same parameters/revision. If you need to keep something after a build, tell Jenkins to archive it before the build is done.
In regard to saving the entire state, I don't think you need to do that. As mentioned in #4, you should be able to reproduce the same build by kicking off the same revision/parameters as the build in question. If you cannot get back to the original state from the same revision/parameters, then that might be something to strive for as debugging is going to be a nightmare. :)
A workspace is an aspect of the project and not a build and that is why there is no link to the workspace from that page. Again, a build is just saved data from a previous run. A project uses the workspace to build stuff and that is why you can get to the workspace from that page.
In regard to how to save artifacts, you must specify the names of the files you want to save. Unless you are trying to save a file called "artifacts", then you should probably use something else. How about **/*.log for all log files? or **/*.xml for all xml files?
Hope this helps.
We are now experimenting with multi-branch Pipeline builds. The main advantage of the feature is that it allows us to automatically create new Jenkins jobs whenever a new branch is created.
However, it also is a bit more difficult to implement than the old way of selecting how to do the build using the UI. Plus, certain features seem to be missing.
For example, in Jenkins Freestyle jobs, we are able to use the Jenkins UI to browse through the workspace, download individual files, and even wipe out the workspace. We found this helpful when builds went awry or if the developer needed a particular built asset that wasn't archived.
I've noticed in the Jenkins Pipeline jobs the UI no longer offers access to the workspace. I know I can archive the workspace, but I really don't want to save it -- especially for each and every build. I simply want to be able to browse the workspace or clean it out if something is causing problems with the build process.
Is there a way to get back this feature via the pipeline? I don't want to archive the workspace for each build (space issues), but I do want to be able to see what the workspace looks like if there are problems.
Freestyle Job with Workspace UI
Pipeline Job. No ability to browse Workspace
You can see your work space in three simple steps:
First, go to the build run you are interested in and click “pipeline steps”.
Then click “allocate node: start”. If you have multiple nodes, you’ll need to do this more than once.
Then you click the workspace link. (it appears on the left pane).
You can also click on Build Artifacts on build page:
Our current setup consist of a single master controlling several slave machine. Usually, the master would issue the test scripts to slaves based on list. Which ever machine is finish a script or idle, it would continue down the list. All of these are tested against a same single build.
We are moving towards CI way and would wish to do something similar to our current plans. I would think it could work the same whereby the master would build, then distribute to the slave for testing. How would this be done?
edit: Just to clarify my position, I have not use Jenkins before, therefore the lack of knowledge for it. Before flaming me into oblivion, I just need someone to point me to the right direction, not asking for a spoon feed solution.
Since you didn't accept hyde's response, I'll assume you're looking for a more detailed answer. First, if you're new to Jenkins I highly recommend Jenkins: The Definitive Guide. Jenkins isn't difficult to use, but it can be hard to get started. That book provides a nice guided tour from the beginning into some of the more intricate parts of running a Jenkins installation. Now on to your question. Jenkins allows you to try things out very quickly without having to really "install" it, so follow along here. You'll also want access to a second computer to make the temporary slave (don't worry, there's no real installation, so just use a coworker's computer).
These instructions look long, but only because I'm walking through every single step. This won't take much time. Also, feel free to click on the little question marks next to all of the fields in Jenkins as we go. By the way, when I quote something, type what's inside the quotes but not the quotes themselves.
Go to Meet Jenkins and scroll down to the Launch button to start Jenkins without installing anything.
Go to http://localhost:8080/. Look! Jenkins is running!
On the left, click Manage Jenkins, then click the Manage Nodes item.
On the left, click New Node. Name it "Foo", select "Dumb Slave", and click OK.
Set "# of executors" to 1 (it's the number of builds you want this slave to run concurrently).
Set "Remote FS root" to "c:\jenkins" or "/tmp" (this will create some files on the slave machine, so use a directory that has write permissions).
Set "Labels" to "tester"
Set "Launch method" to "Launch slave agents via Java Web Start" (you probably don't want to do this in production, but it will allow us to bring up a slave quickly).
Click Save
Click on Jenkins in the upper left corner to go back to the main page.
Click New Job on the left.
Name the job "My build" and select "free-style software project" and click OK.
Check Restrect where this project can be run and type "master" for the label (it should even auto-complete). This makes the build only run on the master.
Towards the bottom click Add build step.
If your master (the current machine) is a Windows machine, select "Execute Windows batch command", otherwise, select "Execute shell".
Either way, for the command type "echo Building". This isn't necessary, but it allows you to see that the build really did something that you told it to do.
At the bottom of the screen, click Save.
You should now be at the "Project My Build" page. Click the Build Now link on the left. Since the build barely does anything, it finishes almost instantly. An entry appears in the history with a blue circle, indicating that the build was successful.
Go back to the main Jenkins screen and add a New Job.
Name this one "My test", make it another "free-style software project", and click OK.
Again, check "Restrict where this project can be run", but make the label "tester" (again, it should auto-complete).
Scroll down and click Add build step again. Select "Windows batch" or "shell" depending on what the slave computer (e.g., your coworker's computer) is.
Type "echo Testing"
Click Save down at the bottom.
Now for the fun part. Go to your other computer (or tell a coworker that their headlights are on and use their computer). Open the web browser and go to http://your-masters-ip-address:8080/
Click Manage Jenkins, and then Manage Nodes.
Click Foo, and click the Launch button. Click through any security/"are you sure" warnings, and you should see a little window saying Jenkins is connected. Now your slave is running.
Go back to your master computer, go to your Jenkins home screen, and click My test in the list of builds.
On the left, click Build Now. This will take a little longer, because it has to contact the slave and farm out the job, but it should finish and add the build to the history.
Click the entry in the build history. Then, on the left, click Console Output.
The log should say that the build was remotely executed on Foo, and have the echo statement. Woohoo! We now have remote builds working.
Lastly, we'll link the builds together. Navigate your way back to "My build" and click Configure on the left.
In the Post-build Actions section, click Add post-build action, and select "Build other projects". Type "My test" in the field (it should autocomplete). Click Save.
Go to the Jenkins main screen, and click the clock/play icon to the right of "My Builds". If you watch carefully, you may see the jobs appear in the "Build Queue" or the "Build Executor Status" on the left.
Wait a minute or so, and then refresh the page, and you should see the "Last Success" time for both of your builds update. Clouds should part, and you should hear angels singing, but don't celebrate just yet.
You now have a master doing the "build" and a slave doing the "test", and a build triggers the test. You could add more slaves and so long as they have the label "tester", the build server will auto-distribute. You could also have many tests following the build, and have the build trigger all of them. That's all the easy stuff, the thing that requires some elbow grease is getting Jenkins to run your build and tests. Start small and work your way up. Oh, and seriously, go buy that book I linked to (it's available in dead-tree and DRM-free ebook, and no, I don't have any connection to O'Reilly or the author, it's just a very useful book) so you have an idea of what Jenkins can do and how best to fit it with your system and what you want.
Is this what you mean:
Go to slave node configuration, and give slave appropriate label, like "unittest". Repeat this for all slaves you want for unit tests (note that slave can have many labels if needed).
Go to job configuration, tick "restrict where this job can run", type "unittest" there.
Also read help texts of these fields!
For more advanced/complex CI setup, also check out node label parameter plugin, if you want to parametrize where a job can run.
Is there an easy way in Jenkins to list all all builds marked as keep-forever? And then, ideally, one click to either unmark the build as keep-forever or to immediately delete it?
In our process, we mark a build as keep-forever if it involves some specific type of failure; that's to keep Jenkins from automatically deleting over time. I need an easy way to get a list of all those keep-forever builds so they don't take up all our disk space over time.
The following XPath query against Jenkins will list the URLs of all builds marked 'Keep Forever':
http://[jenkins_server]/api/xml?depth=2&xpath=/hudson/job/build[keepLog="true"]/url&wrapper=forever
Enter it in the browser and see what it returns.
Now, you can embed it into XSLT-based HTML to get a list with links to those builds. To delete the build you can provide a button that invokes Jenkins CLI:
java -jar jenkins-cli.jar -s http://[jenkins_server]/ delete-builds [job-name] [build-num]
Unfortunately, I do not know how to disable 'keep build forever' with CLI without deleting it.
I was looking for the same thing, and our jenkins is pretty big as well and trying the link:
http://[jenkins_server]/api/xml?depth=2&xpath=/hudson/job/build[keepLog="true"]/url&wrapper=forever
I ended up crashing it.
But as it turns out I only require the last 'keep forever' build of one job at a time, which seems to work way faster. So I use the following instead:
http://[jenkisn_server]/job/[job_name]/api/xml/?depth=2&xpath=/freeStyleProject/build[keepLog="true"]/number&wrapper=forever
which returns the xml with all the numbers of build that are marked as 'keep forever'
You can modify the xpath to fit your needs.