I have a freestyle Jenkins job with multiple git repositories.
I want Jenkins to ignore one of the repositories when generating the changelog for the build (such as for sending out emails or updating relevant Jira issues).
Is it possible to exclude one of the repositories from the changelog?
I ended up working around this problem myself by removing the the repository from the SCM section of my Jenkins job and writing a script to clone and checkout the repository as a build step.
Related
I'm currently trying to set up a build job connected to multiple (3) svn repositories with single pipeline, with Poll SCM scheme. All the contents from the repositories build into a single artifact. Repositories are, e.g., say:
https://myrepo.com/mainSrc/main
https://myrepo.com/libs/library1
https://myrepo.com/libs/library2
When I set all this repos inside Pipeline configuration, the build job successfully checkouts all the paths to the workspace.
However, the point is, I need to track which repository started the build job, to write some conditional steps. Is there a solution for this? I googled for it, there are some ways to obtain svn revision for a path, however it's not what I'm looking for.
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!
I have around 10 repositories that I would like to poll. If a folder is a added in the root folder of any repo, I'd like to trigger a certain build, (the same).
I thought using the Poll SCM plugin but it requires one job per repo and it's not scalable.
Is there any clean way to do this and any plugin that would help?
EDIT: I have a job generating debian packages from folders that are in my 10 repositories (each folder corresponds to a separate package). When a new folder is added, it means a new package is.
I would like then to trigger a packaging build so developers can fetch it from our apt repository without waiting the nightly build
You can use this plugin:
https://wiki.jenkins.io/display/JENKINS/Pipeline+Multibranch+Plugin
As per the manual:
Enhances Pipeline plugin to handle branches better by automatically
grouping builds from different branches. Automatically creates a new
Jenkins job whenever a new branch is pushed to a source code
repository. Other plugins can define various branch types, e.g. a Git
branch, a Subversion branch, a GitHub Pull Request etc.
See this blog post for more info:https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/ "
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.
In Jenkins, I have a "Build" job setup to poll my git repo and automatically build on change. Then, I have separate "Deploy to DEV", "Deploy to QA", etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.
However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it's possible the artifact could be incompatible between versions. So, it's ideal that I ensure that the build and deploy jobs are run using the same git checkout.
Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don't see any options or plugins that do this.
Any ideas on how to simplify this configuration?
You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.
The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like "LatestSuccessfulBuild") at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.