Our team has a freestyle project in Jenkins that allows us to build with a specific TFS change set and deploy to a testing environment. Both of these options are parameterized, but recently, these parameters are no longer visible in the job history sidebar for new jobs.
We expect to see both a change set number if one is provided, but the environment is a required parameter and should always be visible. Since the parameters are visible for builds older than May 11, I thought this was adjustable at the project level and was accidently modified, but I do not see an option for this in the project. I am able to confirm that the project is still parameterized, and builds are still able to be filtered by environment:
Is there an option to adjust the visibility of these parameters in the sidebar so that they appear again for new builds, or is something else happening here?
Related
I am an admin on our Jenkins master but, this button is not available for any builds for any user.
I found this question which has a somewhat relevant answer since we are also using Matrix-based security, however no one has this button showing up on any build
Is there a plugin required to have this feature available?
My version isJenkins ver. 2.105
Keep forever option appears only when relevant, meaning only if you opt in on other option Discard old builds. If not it's irrelevant see jenkins users answer
option only appears if you have chosen to Discard Builds
from the config for the job. (i.e. if you have chosen not to discard
any builds have a certain time/build number, then the button won't
show).
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
I have been using Jenkins for a couple of months now, and have been able to set up a simple CI system.
I currently have a build tab - that will build and deploy 25 different components successfully, based on building from an SVN trunk.
I'm now taking my first branch - some people will develop on the trunk and some will develop fixes on the branch.
I would now like to have CI up and running for both branch and trunk - so would create a second tab - with a repeat of the jobs from the first tab, but this time changing the SVN path to check out from the branch.
As I have rather a lot of jobs and the task is quite repetitive, is there an easy way to do this ? I'm hoping that each job tab might be a single xml that I can edit / rename to give me a second tab ?
Yes, each job is as single xml file, located under $JENKINS_HOME/jobs/$JOB_NAME/config.xml. However there are a number of places in the config.xml that reference it's location, so simply copy-pasting the actual file isn't the best option.
Jenkins UI itself has "copy job" function.
Click "New Item" where you want it
Select "Copy existing Item"
Specify the name of existing item to copy
Specify the name for the new job
Then go to configure the new job and change what you need.
Another tip: may not apply to your setup, but more often than not, there is a "unifying difference" between multiple similar jobs, most often a branch name, or project name, or similar. The value would be that only one that needs to change between otherwise identical jobs, however that changed value may appear several times within the job configuration.
I usually make a "choice" parameter, with a single choice, and put that different value there. The rest of the job references the choice param as a variable. So when I copy identical jobs, I just need to change that 1 value at the top of job configuration page. Everything else falls into place.
I am using TFS 2010 and have a build machine that contains a single build controller running 2 agents.
I have worked out that I can assign a tag of "Nightly" to my 2nd agent and then edit the Build Definition for my Nightly Builds in TFS to only use an agent that has the tag of "Nightly".
Easy enough.
However, the issue here is that if a normal build (Such as dev/CI) came along, it could - in theory- use my nightly agent, which I don't want to happen.
I could go around all our development builds (20+) and add in a tags=normal and tag my primary build agent with normal, but this then relies on people remembering to tag up new builds in the future.
Is there a way to set up my build agent in TFS's Server Admin, so that it will ONLY run items with specific tags? Or is my "go around the houses" approach the only logical way?
Edit
I got around this in the end by making all my builds look for "matchExactly" on empty tags, which means my "nightly" tagged agent will never be used for CI.
I believe the default for build definitions says MatchExactly and has an empty Tags Filter field. This means that by default build definitions will only run on Build Agents that have ZERO tags. So the behavior you desire should be the default, when you tag your build agent with the Nightly tag, no builds will run on that agent unless somebody explicitly goes in and changes the default Agent settings for that build def.
I expect that this agent is already running on it's own server, otherwise there'd be no reason to single it out.
You could give this specific build agent it's own build controller, that way chances of a build associated to the "CI" build controller are zero. unless people chose the incorrect Build Controller for their build definition.
This way you also won't have to go about changing the current build definitions.
I am preparing to move my team's source control from VSS over to TFS 2008.
This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.
I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.
Here are my requirements:
When code reaches a certain point, I manually apply a label to it.
This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
Any of these 25 environments can be on any current or past labeled version of the application.
I need to be able to deploy any labeled version of the application to any of the environments.
I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.
I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?
Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)
By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.
see 4.
I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.
Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.
To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.
The custom build task allowed me to get the latest version from a specific branch and label.
Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.
msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.