I have a Jenkins file in the repository for MultiBranch pipeline.
I have a separate pipeline file for my toll gate into our integration branch. This is located in another repository. Executing it from a webhook from a BitBucket Server and both the branch and commit information is missing from BlueOcean?
Is there some way to set these values so they are picked up by BlueOcean UI?
Related
I am having trouble getting Jenkins multibranch pipeline detect pull requests created in the Bitbucket server (private instance). I have setup the "Bitbucket server webhook to Jenkins" which is triggering the build on master, develop and feature branches except pull-requests. I have defined the build steps in Jenkisfile and can confirm the PR branch also includes the Jenkinsfile.
In the Jenkins configuration, I have enabled "Discover branches" under Branch Sources configuration
Pull Request isn’t a branch, it is usually something that is done prior to publishing to a branch. Usually, the pull request is approved, then published to the master branch.
Ok. After multiple trial and error and google search, I have managed to get the Jenkins Multibranch pipeline work with Bitbucket server. The key was to use 'Bitbucket' (from bitbucket branch source plugin) as the Branch source. Also, I had to include a dummy trigger in my Jenkinsfile for the Jenkins webhook to work from bitbucket
triggers {
bitbucketPush()
pollSCM('0 0 1 1 0')
}
When I build a multibranch pipeline job using BlueOcean it looks into my repository and reads all of my Jenkinsfile for each branch. to initiates multiple build, but I only want to be able to build a job based on a certain branch. Is there a way to only build blueocean?
Thanks
I sounds like your job is a Multibranch Pipeline.
If you create a job that is just a Pipeline (rather than Multibranch Pipeline), you can specify a single specific branch to build.
I am currently using Cloudbees Jenkins Coreas my Jenkins solution.
I am using Jenkins Pipelines to write our Jenkins job configuration. These pipelines are stored in GitHub repositories. Each Jenkins job when created is connected to a GitHub Repository where the source code is pulled from, and that's where the Jenkinsfile is stored and Jenkins reads from.
Below are some high-level photos for how our Jenkins jobs are configured.
The advantage of the way these jobs are configured is the Jenkinsfile is always read from the master branch. Meaning if a rouge developer tries to remove stages from the Jenkinsfile from within there own branch, it doesn't matter because the Jenkinsfile is always read from the master branch (which is always protected).
However, the one massive drawback to this - is how do teams and developers who are devops engineerings make changes to the Jenkinsfile? For example, let's say a developer creates a branch called feature-jenkins-search and they edit the Jenkinsfile adding a new stage in the pipeline. Whenever they push these changes to GitHub to test - they can't test as it's always read from the master branch? Meaning devops engineerings have to work directly on the master branch? Surely this is not the best way to go and there is a better configuration to set?
We do want to still provide the security that if a developer is rougue and
You should really look into the Jenkins multi-branch pipeline feature. The Jenkins multi-branch pipeline allows to create a single configuration item in Jenkins (a bit like a folder) that can detect all the branches and pull requests in a GitHub repository with a Jenkinsfile and build them using automatically created jobs. Inside this multi-branch pipeline object when it is configured in Jenkins, you will find a number of jobs to build the various branches and pull-requests in the GitHub repository.
So your developers should maintain a Jenkinsfile in every branch they work on in GitHub to build that branch in your Jenkins server.
It is possible to make the Jenkinsfile do branch specific handling if required with conditional stages / when conditions in the Jenkinsfile pipelines in each branch.
You can lock down the master branch so that code and Jenkinsfile changes from other branches can only be merged with an approved PR (pull request). There is good integration between Jenkins and GitHub such that you can configure the master branch to only allow a PR to be merged if the PR is buildable in Jenkins. So if developers add new stages / processing to a Jenkinsfile on a branch being merged to master, it should be validated so that builds of your master branch are not broken.
There is a lot of configurability in the Jenkins multi-branch pipeline object for detection and handling of branches and it may be necessary to experiment to get it right for what you need with your team. If you cannot find this feature in Jenkins, it is probably because the correct Jenkins pipeline and GitHub related plugins are not installed.
You could also have a look at a similar Jenkins feature called the Jenkins GitHub Organization Folder which allows to detect and build all repos and branches at a GitHub Organization level. But when starting out, I would suggest to look into the multi-branch pipeline at the single repo level first.
These features are discussed in the Jenkins pipeline documentation. We use these features with our internal GitHub and Jenkins server and it works very well.
I think you will find the idea of using a single Jenkinsfile in the master branch to be used for building all branches is unworkable, as you have seen!
We are using jenkins for manual triggered jobs to deploy some code.
Jenkinsfile describing our pipeline is located in a jenkinsfile dedicated repo (not in deployed code repo).
We are using declarative pipeline syntax and shared libraries in our jenkinsfiles.
In BlueOcean interface there are 2 interesting attributes (branch and commit) automatically filled when using plugins to trigger pipelines (like github organization).
I'm searching a way to set/update these 2 attributes manually from within the pipeline code for our manual pipelines.
Job description and name can be easily updated using something like :
stage('Set pipeline description'){
steps {
script {
currentBuild.description = "Deploying branch ${branch} on ${targetEnv}"
}
}
}
But I didn't find anywhere how to update branch or commit values.
Did anybody try this ?
This issue is reported as bug (see link).
"We are using GitLab web hooks to trigger Jenkins Pipeline project builds on new commit push to GitLab. Build is triggered, CI commit status report is being sent back to gitlab, but can't see branch and commit field in Header-details element."
Please vote on this issue on Jenkins CI website if you want for the issue to be resolved sooner.
I'm using the Bitbucket Branch Source Plugin to automatically configure multibranch pipeline jobs for every repo under a specific project directory within Bitbucket. One repo contains a valid Jenkinsfile. The master branch for that repo builds and deploys fine. However, pull requests for that repo are not being built. I see the following logs:
Connecting to <URL> using <credentials>
Looking up repositories of team <Project>
Proposing test-project
Connecting to <URL> using <credentials>
Looking up <Project>/test-project for branches
Checking branch master from <Project>/test-project
Met criteria
Looking up <Project>/test-project for pull requests
Checking PR from ~<user>/test-project and branch feature/thing
Does not meet criteria
The specified branch for the pull request does contain a Jenkinsfile, so I do not understand why it says that the criteria are not met. Any suggestions?
The "Automatic branch project triggering" option is set to the default .*
I'm using the following plugins to Jenkins:
Bitbucket Branch Source Plugin 1.8
Branch API Plugin 1.10.2
GIT Plugin: 2.4.0
Pipeline 2.4
Pipeline: Multibranch 2.8
Pipeline: SCM Step 2.2
SCM API Plugin 1.3
... others omitted for brevity
Well, I feel dumb.
Jenkins did not have read permission on <user>'s fork of the repo containing the branch for the PR.
When you make a PR, all the users with access to the repository receiving the PR are able to view it without issue, so this may be an issue with Bitbucket Server itself (I'm on 4.2.0) not allowing those users to have remote read access to that branch once it has been included in a PR.