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/ "
Related
Short explanation:
There are many repos in our Git
Each repo has it's own Jenkinsfile who has it's own separate Job at Jenkins
All Jenkins files are doing 99% the same thing!
What we want to achieve at the moment:
Build one Jenkinsfile for all repo
Maintain branches in between repos
Delete if we can the current Jenkins files of each repo and use the only generic new file.
Have the versatile to use and manipulate parameters so Jenkins file won't be affected by any other repo config
Solutions for now:
Remove all Jenkins files in all repos
Re-configure the Jenkinsfile PATH in Jenkins gui website to direct to our new file
Put a config .yaml file in each repo who will contains all the relevant information of each repo (like key-value)
So, when each repo will be triggered, our new Jenkinsfile will load the config file and use the parameters to proceed all the stages related to the config file.
I would be happy to hear ideas / examples / snippets from you guys! It will highly help me!
Regards
Niv
(Answering due to lack of reputation for comment. Please excuse)
Hi #n1vgabay
If you are using Bitbucket for your SCM, then you may try these:
create a Organization Folder/Bitbucket team Project inside Jenkins (From Jenkins --> New Item--> Organization Folder or Bitbucket team/Project)
Update the config to filter all the repos (or regex them) under the Project inside your SCM. This will create all the repos as individual MB pipelines with all the branches under them as individual jobs. Also with Bitbucket Server Integration plugin, it automatically creates Webhooks for all the repos to trigger the jobs accordingly upon the events (Push, Commit, PR opened etc)
Using Remote JenkinsFile provider plugin, you may choose to place your Jenkinsfile elsewhere in another Proj/repo and call them from this config.
This Jenkinsfile can have all the steps you need and will run the same for all the branches which run as individual MB jobs.
More details on the same can be obtained from here.
Now if you want to use individual jenkinsfiles, then you might have to come up with having Jenkinsfiles specific to each repo which might make it complicated and your Jenkinsfile at the root folder level will have to call the Jenkinsfile present in your repo/branch level across all the repos and branches.
Hopefully this helps! :)
I'm in the process of migrating git-based projects to use a shared Pipeline definition from a governance tier built with Jenkins Templating Engine.
In the process of testing I cloned the project and pushed it to a new repository in Bitbucket where it was recognized by Jenkins and the template was used immediately based on the definitions in pipeline_config.groovy. However, this is not a sane migration path for existing projects. How do I get Jenkins to start using the template on branches without Jenkinsfile and the Jenkinsfile on branches with a Jenkinsfile.
The result of of "Scan Multibranch Pipeline Now" according to the logs is ‘Jenkinsfile’ not found. Skipping. I assume that a new project regonizer is provided by the Jenkins Templating Plugin.
I assume that every project with Git Flow has to perform this migration, so I'm confused there's no documentation.
I'm using Jenkins 2.306 and JTE plugin 2.3.
It seems that newer versions of JTE or Jenkins allow a mixture of branches with JTE and without.
In case you have to deal with versions that don't do the following:
Once I removed Jenkinsfile from every branch and put a pipeline_config.groovy on every branch the Multibranch Plugin started recognizing the project first as removed and at the next scan as present with all branches which were all using the Jenkins Template Engine.
Not the best migration imo, but a great opportunity to cleanup old branches. Since my project was using Git Flow I needed to make a technical hotfix release to also migrate away from Jenkinsfile on master.
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.
I have a task that I want to realize with Jenkins, but I don't know how to do it.
I have a view full of jobs, all pointing to the same svn repo. Each job build one maven module present on the svn repo.
Once a year, we release a version, and therefore we create a new branch for the development on the future new version.
In Jenkins, it means that I want a view with all my jobs pointing on the released version branch, and a new view with the same jobs, but pointing on the future version branch.
I know that I can do that manually by cloning and then modify the branch for all the jobs, but I want to do that with the least number of actions possible (ideally one :-)).
I take a look at Jenkins built-in possibilities and in existing plugins, but I found nothing and I have no idea how to do it.
Is there a possibility to script that kind of job ? Or a plugin doing that ?
Thank you,
Seb
I suppose your future versions are developed on the trunk. So the URL for these versions is always the same (ex: http://svn.yourcompany.com/project1/trunk).
I propose to group your trunk jobs in a dedicated folder using the CloudBees Folder plugin.
This plugin will group all your jobs in a physical folder in your Jenkins home folder (ex: jobs/trunk).
When you want to create the new jobs for the release branch, you write a script which:
Copy the jobs/trunk folder into jobs/release_2.0
Replace http://svn/.../trunk with http://svn/.../branches/2.0 (you can use a regexp to do that)
Rename all the jobs (you just need to add 2.0 at the end of all job names)
Reload the Jenkins configuration
It should work :)
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.