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 :)
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've set up multibranch pipeline to track my repo and automatically build and test for all merge requests. It works wonders, however, I noticed that Jenkins creates a new workspace for each new branch. It is a pretty big project with a heavy build process and a lot of non-tracked cache files, that mostly stay valid from one version to another - so if instead of a fresh git checkout it would re-use previous workspace, it would build much faster (and also not use up so much hard drive space).
How can I configure it to re-use the same workspace for different branches?
After researching the issue, I found out that this is not something I can do with multibranch pipeline, so I switched to using the regular pipeline project. Now every build uses one of the available workspaces, so they end up re-using previous workspaces and the same cache files that really speed up the build.
Jenkins for MultiBranch projects by default uses isolated workspaces for every branch.
Jobs within the same branch use the same workspace.
A possible solution for you is to use ws(path) inside a pipeline.
node("agent_name") {
ws(workspacePath) {
echo '...'
// ..
}
}
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/ "
My understanding of Jenkins is that, if you have a repo (say a Git repo) that is tied to a Jenkins build, a check-in will trigger a complete repo re-build. But if you have a number of applications as part of your repo, is there a way to limit which applications will rebuild in response to a check-in? If you make a change to one application, is there a way to set up your Jenkins build process to that that check-in triggers a rebuild of that application alone?
I'm sorry but your understanding is wrong... Jenkins and Git talk to each other using hooks and if these hooks are connected to your build, only then will they build the application/branch in your repo... So unless you have specified that everything must be built, then all the application will be built, otherwise the one you checked in ...will trigger only that build
If you want, you can create a new job and add the GIT SCM hook(during configuration) and do a check in, it will build only your project and any other project that is using the same hook- key point to note here :)
So if all your applications are building then you have a configuration issue
Hope this helps :)
We have a Jenkins server where I have already defined my job. It uses Perforce as SCM.
I would like to replicate all the steps that Jenkins takes to build the project but use the files in my local workspace instead. Basically, I would like to run a jenkins build locally based on a job defined on another server.
How would I do the same?
Something like what I created for my Perforce users might work for you -- I added a job in Jenkins that will grab shelved files (so, the user would need to shelve the files), create a build from there, then let the user know if it was successful (they also have the option of running tests or creating a deployable build). The gist of it is to request the shelved changelist #, then do this: "p4 unshelve -s %SHELVEDCL% " and proceed as usual. They use it when they feel like it; it's been useful. But it does require access to Jenkins.
1) Install Jenkins on your local workstation (if you have no already done so).
2) Copy the /Jenkins/jobs/ directory to the /Jenkins/jobs/ directory on your local workstation.
3) Fire it up and edit the Perforce workspace (and any other settings) as necessary.
IMO, you should probably takes these steps:
Create a new Jenkins job from the existing one. 2) Modify the job to
be a string "parameterized" job where you pass branch-name as the
parameter. You can do using "This build is parameterized" option in
the configuration of the job. 3) Under the configuration of the job,
for Source Code Management section, change the Branch Specifier to
use the String Parameter variable name (created from #2 above).
4) Create your feature branch on Perforce and make intended changes
there. 5) Run the newly created job with your branch as the parameter
to it.
Hope this helps.