I have a Jenkins job with two promotions steps. The first promotion creates a Jira ticket. The 2nd promotion needs to close the Jira ticket created in the first promotion. How can I pass the Jira ticket information (ie key/id) from the first promotion to the second promotion?
Possibly the following contains the information you're after:
☑ Promote builds when...
Promotion process
Actions
Add action
JIRA: Add related environment variables to build →
Extracts JIRA information for the build to environment variables.
Available variables:
JIRA_ISSUES - A comma separated list of issues which are referenced in the version control system changelog
I was able to resolve this issue by using the Copy files back to the job's workspace on the master node plugin in the first promotion step, and then use the Copy artifacts from another project plugin in the second promotion step to get those files.
Related
I need some help to ingrate Jenkins with jira my user case is this one : i would like to feed urls of builds related to a Jira fix version. This is important for us ( audit & compliance purposes )
How can i do that ?
Think you in advance.
regards,
This is how we handled it:
Add a custom text field to every jira issue type. it can be 'build number' or 'build url' or whatever information you need to display regarding the jenkins build
Create a python script that receives as parameters a list of jira issues and a build number.
Using the JIRA python module (pip install jira), the script creates a connection to jira, goes over the list of issues and updates the custom field above to the given build number.
if the list of issues is not known in advance, then instead of parameter you can provide (or hard-code) a JQL query which the script can use to obtain the list of issues.
Depending on your needs, you may want to skip updating issues who already has a build
number set (either manually or by a previous build)
(Sorry, i can't share exact code but it shouldn't be complicated.)
In your Jenkins build, add a 'batch command' item which runs that python script with the appropriate parameters.
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.
In Jenkins, if we use Post-Build Trigger to start another build
What are ENVs available to the new build.
I need to identify, parent builds Name, Build Number, Last Successful Artifacts' URL etc.,
In simple words, how to get upstream project info on a downstream project
Is that possible
You can use the Parameterized Trigger Plugin to pass variables from one build to the next. It is used in much the same way as the Post Build Trigger plugin you mentioned you're using already.
It defines some variables that are passed through to the next job, but you are free to define your own in the box provided, e.g:
ARTEFACT_URL=www.example.com/builds/$BUILD_NUMBER #using another variable from this build
SOMETHING=VALUE
UPSTREAM_BUILD_NAME=myProject
UPSTREAM_BUILD_NUMBER=$BUILD_NUMBER
#note that you shouldn't override any properties likely to be set in subsequent builds!
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 a project that has 3-5 different mercurial branches going at all times. I want to schedule a weekly Jenkins test to run our tests on all relevant branches.
What I want, I think, is a parameterized build, with the branch name as the parameter, and then to have a list of branches, and once a week, run the parameterized build with each of the parameters in the list.
However, I see that you can't send parameters into a triggered build. I assume that there is a plugin for this. Is job Generator the correct plugin? Is there something better?
I should mention that currently, we are doing this with multiple SCMs, and having the body of the build have a sh loop that runs through each directory and runs the tests. This is really inefficient, and a pain to maintain...
I can suggest one solution but it couldn't be called elegant.
Firstly, you need create multi-configuration project (aka Matrix project).
In this project you need declare one node (it can be already existed master node)
And one type of axis (for example BRANCH - be careful don't use Jenkins Set Environment Variables variables) with values corresponding for each branch (for example default, testing, devel, etc).
After you need add in your project build action in which you need check environment variable (previously declared $BRANCH) and discover for which branch this build was launched (the main idea is illustrated by example with using bash).
And finally you need manually get sources from corresponding branch.
Next build steps can be the same for all branches.
This approach have set of drawbacks:
1. You can not triggered this project by changes in repository (you can check using Mercurial plugin only one branch).
2. All subprojects will be rebuilt even if they have not changed.
3. Appropriate only for statically defined branches.
4. Not elegant.
But it has one advantage versus parameterized build:
1. All artifacts (and build logs) of branches is stored in separated directories (because they are separate subprojects).