I have a pipeline whos job is to take attached submodules, bundle them up in a zip, and push them to an artifact repo only on a merge to the primary branch; all of this logic works fine.
However, because a merge event gets trigged for opened and merged for merge requests, for every merge into the primary branch there is always an effective "no op" build because it will receive the opened event.
From the documentation around option filtering in the generic webhook, it isn't clear to me if a no-match also won't trigger a build, or simply will product a value of "". Here is the documentation:
Value filter
Optional. Anything in the evaluated value, matching this regular expression, will be removed. Having [^0-9] would only allow numbers. The regexp syntax is documented here.
This simply leads to the javadoc on regex.
I would love to not trigger a build at all, even a no-op build, unless the state is "merged"
Yes, you can do it, but you need to add Optional Filter in another way.
In the end of GWT plugin configuration of your job, there is a global Optional Filter section:
Related
We are using Jenkins Pipeline Multibranch Plugin with Blue Ocean.
Through my reading, I believe it is quite common to tie your project's build number to the Jenkins run, as this allows traceability from an installed application through to the CI system, then to the change in source control, and then onto the issue that prompted the change.
The problem is that for each branch, the run number begins at 0. For a project with multiple branches, it seems impossible to guarantee a unique build number.
You can get the Git branch name from $GIT_BRANCH and add this to $BUILD_NUMBER to make an ID that's unique across branches (as long as your company doesn't do something like get themselves taken over by a large corporation that migrates you to another Jenkins server and resets all the build numbers: to protect against that, you might want to use $BUILD_URL).
Only snag is $GIT_BRANCH contains the / character, plus any characters you used when naming the branch, and these may or may not be permitted in all the places where you want an ID. ($BUILD_URL is also going to contain characters like : and /) If this is an issue, one workaround would be to delete unwanted characters with tr:
export MY_ID=$(echo $GIT_BRANCH-$BUILD_NUMBER | tr -dc [A-Za-z0-9-])
(-dc means delete the complement of these characters, so A-Z, a-z, 0-9 and - are the characters you want to keep.)
Maybe instead of a unique (global numeric) build number you might want to try a unique (global) build display name?
According to "pipeline syntax: global variables reference" currentBuild.displayName is a writable property. So you could e.g. add additional information to the build number (in order to make it globally unique) and use that string in subsequent artifact/application build steps (to incorporate that in the application's version output for your desired traceability), e.g. something like:
currentBuild.displayName = "${env.BRANCH_NAME}-${currentBuild.id}"
Using the build's schedule or start time formatted (currentBuild.timeInMillis) as a readable date, or using the SCM revision might be also useful, e.g. resulting in "20180119-091439-rev149923".
See also:
https://groups.google.com/forum/#!msg/jenkinsci-users/CDuWAYLz2zI/NLxwOku4AwAJ
https://support.cloudbees.com/hc/en-us/articles/220860347-How-to-set-build-name-in-Pipeline-job
One way is to have a Job that is being called from all branches and using it's build number. That job can be just a normal pipeline job with a dummy Jenkinsfile like echo "hello". Then just call it like this
def job = build job: 'build number generator', quietPeriod: 0, parameters: [
string(value: "${BRANCH_NAME}-${BUILD_NUMBER}", name: 'UID')
]
def BNUMBER = job.getNumber().toString()
currentBuild.displayName = "build #"+BNUMBER
echo BNUMBER
Not sure if that UID parameter is needed but it forces all calls into "build number generator" job to be unique so Jenkins wouldn't optimize builds that happen at same time to use same "build number generator" job.
You can use an external service to manage a unique build number for your project. It helps to get unique build numbers across branches and across CI servers too.
https://www.nextbuildnumber.net/
I've configured a service hook in VSTS to connect to Jenkins. I'm able to use the Jenkins extension to trigger a Jenkins job if it's not in a subfolder. E.g. http://myhost/job/Always%20succeed/
In that case, I can simply connect like this and run my job:
If my job is nested, however, I can't figure out how to connect. Here's an example: http://myhost/view/Production/job/Automation/job/Test/job/My%20Job
I've tried using just the name (e.g. "My Job"), the whole url, and a dot notation (Production.Automation.Test.My Job). How can I make this run and where can I find more documentation?
It's pretty nuanced and one could argue buggy. First off, I can reach the same job with two urls:
http://myhost/view/Production/job/Automation/job/Test/job/My%20Job
http://myhost/job/Automation/job/Test/job/My%20Job
Turns out the latter is the way to go.
I tried the following name, and it tried reaching the corresponding endpoint:
Automation/job/Test/job/My%20Job <- name used in VSTS "Job name" field
/job/Automation/job/job/Test/job/My%20Job/build <- url attempted, failed (404)
Note the double job/. Then I tried the following with better results:
Automation/Test/job/My%20Job <- name used
/job/Automation/job/Test/job/My%20Job/build <- url tried, success
It's a bit concerning that the pattern isn't consistent regarding the double "job/" part but whatever.
I have a parent jenkins multijob that calls 3 children jobs, passing to the children the same parameters the parent was built with.
Each child needs to use the same timestamp as it is a unique identifier that each child needs to search for on a webpage.
My problem is this:
When the parent is built, the "name" parameter is set to ${BUILD_TIMESTAMP}, lets call this "02201200" short for Feb 20, 12:00. Each child is called with "pass current job parameters". However, instead of each child receiving 02201200, they each receive ${BUILD_TIMESTAMP} and fetch this value again (eg 02201204).
How do I force the parent to evaluate ${BUILD_TIMESTAMP} and pass its evaluation to the children instead of the variable itself?
One possible solution would be to write the value of this time stamp to a file. Then you could reference that value in subsequent jobs via the "Parameters from properties file" option. Obviously you would just keep overwriting this file every time your job sequence runs.
I used this method and also ended up generally saving all metadata (system/environment variables, jenkins parameters, and build properties, etc) into a properties file and even archived them. This approach simplifies/works around many problems I had. Now, every build has its metadata archived, for downstream jobs or later references, I can get all necessary information from this one file; no extra parameters need to be passed around.
Furthermore, if anything goes wrong, the metadata is very helpful for investigating. I would recommend this simple strategy as it has proven extremely useful to myself and my team.
When I run a manual build, I'd often like to mark it with documentation to show why I ran it. Is this feature available with a plugin?
thank you!
I would approach this by adding a build parameter as a string, as above, then use the Description Setter Plugin to set it from that parameter. We use something like this for the regex:
^\++ : BUILD DESCRIPTION : GERRIT_CHANGE_OWNER_EMAIL=([^#\s]*)\S*, BUILD_USER_EMAIL=([^#\s]*)\S*, GERRIT_BRANCH=(\S*), GIT_COMMIT=(\S{8}).*$
and this for the description:
\1\2, \4, \3
As a result we get:
jspain, 0ee3198b, master
or when it fails, we get:
Failed due to timeout.
wayvad, fc7bdf2a, master
this "Failed..." text comes from the Build Timeout Plugin
I am not aware of a plugin that can do this, and after a brief search I could not find one to do what you describe.
You can mimic this behavior by adding a string parameter in the job that takes a default value of automatically started when it's normally run, but that you can change to my reasons for this build when starting it manually.
You could then use a batch (or groovy or ) build step to print the contents of that parameter into the build log. If you do some sort of SCM checkout I'm not sure how close you can get it to print to the line that contains the username that started the job, however you can click on the view parameters button in the job build and see what was in the field quickly without having to parse the logs.
The downside of this is that parameter would have to be added to each job.
I want to add a conditional parameter to jenkins job. In other words, I want to add a boolean parameter when checked, another string parameter appears to the user when they build the job. If not checked the string parameter should not appear as a parameter when the user builds the job (Kind of a similar behaviour to the conditional steps of jenkins but on parameters.). Is their a plugin for that?
In the image below, if repo_update is not checked: Clean and Changesets should not be present to the user if they are building the job.
You might want to look at the Multi job plugin
Make the parent and child two separate jobs. This to me makes more sense logically.
In the build part, run the parent job first.
Based on a condition, the child job can run.
You can add the child params in the child job only, so people who configure the parent job will never see the child params
This to me feels like a cleaner implementation.