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:
Related
I have a job to maven build our project, we now have one job per release version. As the number of releases grows, there are too many jobs and very hard to find the one we need.
I wonder if there is a way to launch the same job with different parameters? The problem is one job only has one workspace, so I'm not sure if it's possible?
Thanks.
Use This build is Parameterized option to build the jobs. Using this you can build the same job for different parameters. You will be asked to enter the parameter before building or you can also give a default parameter and you can have multiple parameters.
It is good the archive the artifacts which you need later.
You can also have the option keep build forever, this will keep the builds permanently Ir-respective of the number of builds to keep.
To use above option you should enable Discard old build option.
You can also link your repository directly to Jenkins which will trigger the job whenever a new commit is made to master or a new tag is created.
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.
I have a job called "development" and another project called "code analysis". At the moment we have two different jobs and different workspaces, but same code; is there any way we could use the same workspace for multiple jobs?I checked the plugins available in Jenkins but I haven't found any suitable one.
Suppose your "development" Jenkins job workspace is /var/workspace/job1. In the "code analysis" job configuration page, under the tab General click on Advanced... and select the option Use custom workspace and give the same workspace /var/workspace/job1 as of your "development" job.
if you were not able to find Use custom workspace you can located it under your project configure>General>Advanced>Use custom workspace
There is a Jenkins Plugins which enables you to create a shared workplace a setup them on every job which need the files from that given repository.
Use Case:
Similar to what you need, first create two jobs from the same Git Repository, then go to "Manage Jenkins" and you create a Shared Workspace. And point to it, on every job you need to read from that files.
Jenkins Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Shared+workspace+plugin#
PS: You should look into "Known Issues" could be a deal breaker for your needs.
sometimes, on fresh copied job, shared-space url parameter not saving to config on first "save", you should save job twice to be sure.
^^ This one it's still unresolved, I tried and still happens. After some several saves (just to be sure) the job runs perfectly.
I tried the inheritance plugin and whoa! that thing is a sledgehammer when all I have is a tiny nail.
I ended up adding a Post-build Action of "Trigger parameterized build on other projects" with "Build on the same node" and a "Predefined parameter". The downstream job needs to have a parameter of the same name defined (WORKSPACE_PARENT) but you can leave it blank. You then define the downstream job with a custom workspace (under General > Advanced)
I chose a post-build action because the actual success of the build job is independent on the results of the downstream build (for now). If you want to bump the results of the downstream job up to the parent job, you need to add it as a build task, not a post-build action.
It works great for what I need.
Parent's post-build task:
Child's custom workspace:
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.
I have a build area (BuildArea) checked in, which contains shared scripts and wrappers and whatnot that I use to build a project.
This is rarely updated.
Separately, I have various projects (Proj1, Proj2, Proj3...) under development which update regularly.
Standard flow is to checkout the latest source files from a project (e.g. Proj1), and then build the project in my build area (BuildArea).
The next day there's an update to Proj1 and also a Proj2, which I also want to build in my build area.
All these builds only read the files in BuildArea; no modifications are made except to create a unique results directory.
So, my questions are:
1. Can I create a Jenkins job that maintains a build area (BuildArea) and updates daily for example.
2. Can I then kick off independent Jenkins jobs that run within that build area and dump their results there?
The main reason I want to do this is that there are many projects run during the week and the build area is enormous, so checking out a local build area for each project is a big waste of resource.
Yes, this should be possible. Set your primary job with a custom workspace and have it store the files in a networked location, and then set up the scripts from your smaller jobs to access those files directly. We use clearcase and i had set up something similar with snapshot views. Your first job will just have the scm step, and your smaller jobs will only pull the files for your project.