I make builds in Jenkins many times a day and I would like to automate it a little bit, but still access it through web interface.
I'm already selecting job with URL (and building this URL with very simple Alfred workflow) but I would like to also select a branch – we have many branches in repo and 90% of time I want to select master of develop
jenkins.skypicker.com:8080/job/beta/build works great for selecting job, but is there a way to select branch, something like jenkins.skypicker.com:8080/job/beta/build?branch=origin/master?
You can, theoretically, use the Parameterized Build feature to define a parameter later to be used with GIT plugin configuration. Then you should be able to use the format of url like this:
http://jenkins.skypicker.com:8080/job/beta/buildWithParameters?BRANCH=origin%2Fmaster
Be careful with the special character in the branch name though. If you can avoid it by specifying a branch name in the form of origin/$BRANCH it would be safer...
Remember that in order to start the build process one must use POST method, not GET - just a side note...
Anser by #Łukasz-rżanek is right, just adding a few notes on which I've stumbled
Set this in Job configuration:
and run it
#!/bin/bash
JOB_NAME="Beta"
JOB_BRANCH=""
JOB_TOKEN="TOKEN"
JENKINS_URL="http://jenkins..."
crumb=`curl "$JENKINS_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,\":\",//crumb)"`
curl -H $crumb -X POST $JENKINS_URL/job/$JOB_NAME/buildWithParameters?token=$JOB_TOKEN
Related
In our project, we have a release-workflow workflow executing every time our master branch is updated, which includes an optional manually-triggered job called Production Deployment.
Now, the problem I have is that in order to see when was the last deployment of a specific microservice, I need to expand all workflows in CircleCI and search where the Production Deployment job was triggered and succeeded (green icon).
Is there a way to see all executions of Production Deployment job in one page? So, on this page, I'll see when was the last time this job was triggered/succeeded.
I guess, in theory, it would be something like /{project}/jobs/production_deployment
The only thing I was able to find is Job Legacy View, but it shows you all jobs in a project, instead of specific one.
You can't do that type of filtering in the UI (not to my knowledge). But the API is your friend.
You can use the "Recent Builds For A Single Project" CircleCI API v1 endpoint, combined with some jq magic. For example:
curl https://circleci.com/api/v1.1/project/:vcs-type/:org-name/:project?filter=successful -H "Circle-Token: <circle-token>" | jq '.[]|select (.workflows.job_name == "Production Deployment")|.build_url'
I am switching from the github pull request builder plugin (for security reasons) and am trying to get the same functionality from Pipelines (using different plugin). I think I have just about everything, however I can't seem to find a way to re-trigger a build simply by a trigger phrase like in github pull request builder plugin. Is that possible via pipelines?
By trigger phrase, I mean that a user can make a comment on the PR saying "Jenkins re-test" and it will kick off the build again.
You can put a condition at the top of the build script to check for the message. You can access the changesets using currentBuild.ChangeSets. The last changeset is at the end of the array. Then you need to access the last element of that changeset. Finally you can access the message via message property. You can then search for your keyword.
I am doing the opposite (not triggering the build with a phrase) but never tried for pullrequests though.
Another idea is to use the "ignore builds with specific message" property and setting this message to be a regex with look ahead that accepts everything except the keyword. I don't really recall the syntax though :/
I'm aware that both GitLab and Jenkins have integration points with one another, however for reasons beyond my control I am not able to use either.
It's easy to pass parameters to a job telling it which branch, even which commit to build. However I just can't seem to tweak it to the right configuration where it will build the merge request number I pass in as a parameter.
I need to do this with the out-of-the-box 'git' functionality in Jenkins. (Can't use the GitLab Merge Request plugin because it requires polling of the repo.) This job must be initiated manually, and the merge request number specified via parameter. I will not be triggering it with a webhook from GitLab either. This requirement is a manual and on-demand build of a specific merge request.
Is it possible, and I'm just missing something (not) obvious?
So no one else has to endure figuring this out themselves ... yes... Jenkins can build a GitLab merge request out of the box, with no crazy plugins.
In Jenkins, in the Source Code Management section, click Advanced, and set the Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
then, in the Branch Specifier field, use this:
origin/merge-requests/${MR}
where ${MR} is a parameter passed to the build - the number of the merge request to get.
This is what works for me as of Apr 2022 (Jenkins 2.303.2)
The other answers seem to now be outdated (2016 & 2018) and don't work for me (however pointed me in the right direction).
Using gitlabMergeRequestId gave me some weird huge ID for a merge request that didn't even exist in my repository (I don't know where that comes from) & MR seems to be an old placeholder back in 2016(?).
Here's what works for me:
1. Checkout of the commit
Set Pipeline > Repositories > Advanced > Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
Set Pipeline > Branches to build > Branch Specifier to:
origin/merge-requests/${gitlabMergeRequestIid}
N.B. gitlabMergeRequestIid is not a typo & differs from gitlabMergeRequestId
2. Specifying branch in Pipeline script
With the above, checkout is successful but you still need to specify what branch your pipeline script will use.
Use the gitlabSourceBranch environment variable, which works in your script for the Git plugin (didn't work for me whatsoever for the branch specifier 🤷♂️).
branch: '${gitlabSourceBranch}'
...
End result (excluding script):
P.S. in case the placeholders change again or this doesn't work, check https://github.com/jenkinsci/gitlab-plugin#defined-variables
In Jenkins, in the Source Code Management section, click Advanced, and set the Refspec to:
+refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
then, in the Branch Specifier field, use this:
Here are the variables that you can occupy https://github.com/jenkinsci/gitlab-plugin#defined-variables, but for this case you should occupy.
origin/merge-requests/${gitlabMergeRequestId}
where ${gitlabMergeRequestId} is a parameter passed to the build - the number of the merge request to get.
I have implemented GitLab webhook and it worked correctly
I'm constructing some build scripts using FAKE for a TeamCity setup. Part of my build requires me to access the teamcity.build.branch parameter, however because it's not an environment variable, I'm not sure how to access it.
I've tried adding %teamcity.build.branch% to an environment variable in TeamCity but it doesn't seem to like that. I also can't access it using the FAKE git module because team city agents don't use git to get the project files, TeamCity hands it to them.
How would I go about getting the teamcity.build.branch parameter through to my FAKE scripts? Ideally I'd like it as an environment variable so I can pick it up straight from within the script, but I'm open to any other ideas.
Try passing %teamcity.build.branch% as a parameter in your build step.
I figured it out with a bit of help from #Nadeem's answer.
I now have my build.bat/cmd file taking in a parameter which I'm then passing into my Fake.exe call like so:
"packages\FAKE\tools\Fake.exe" build.fsx branch=%1
Then inside my FAKE code I'm using the getBuildParamOrDefault "branch" <default branch here>.
I'm then using this as the branch name. I'm also using a string split on the build param that comes in because normally it's in the format of ref/head/<branch name> and I only want the branch name.
I also had to pass in %teamcity.build.vcs.branch.<project>% instead of %teamcity.build.branch% as my agents didn't like the implicit requirement. I'm not entire sure why this is but all is working well now.
I wonder, if it is possible to create generic parametric jobs ready to copy where the only post copy action is to redefine its parameters.
During my investigation I find out that:
- I can use parameters in svn path definition
- I can define the flow of builds using *Build Flow Plugin*
However I cannot force Jenkins to use parameters inside job names definition for promotion process. Is any way to achieve that?
Since I create sometimes branches from master I would like to copy the whole configuration of jobs but only one difference most times is that in the job name definition I replace master with branch name.
Why it not possible to use a parameter as the branch name?
Then when you start to build the job, you can input the parameters based on the branch you want to build.
Or find some way to get the branch info and inject it.
For example, we have one common job, which will monitor maybe 20 projects, if any of those job was merged into git, our gerrit trigger plugin will start to work, and all of job name, and branch is got dynamically from parameters.
Hope this works for you.