Gerrit Version: 3.2.3
Reviewers Plugin: aebc8574de - (3.2.11-SNAPSHOT).
We have 5k gerrit repositories and in that 1k repositories we have branches dev/test/2022 & dev/release/2022 uniquely.
Is it possible to configure the default code reviewers for above given branches in multiple repositories globally at one place? instead of configuring it in each repository explicitly.
So that whenever developer pushes a change in any of the specified branch in a repository, it need to add the reviewers automatically.
Although the reviewers plugin is configured per project in the reviewers.config file, missing values are inherited from the parent projects, so a global default configuration can be done in the reviewers.config file of the All-Projects root project (or another parent project), and the other projects can then override the configuration in their own reviewers.config file, if necessary.
See the plugin documentation here.
Related
We have Jenkins set up with 7 multibranch pipeline projects, each building off the same git repo, but for different target platforms. Each of these multibranch pipelines builds a number of branches. We currently set which branches each multibranch pipeline builds by using the following property in the multibranch project configuration:
Branch Sources -> Git -> Behaviors -> Filter by name (with wildcards)
Currently, each multibranch pipeline has the same string of branches in this Filter by name (with wildcards) field. Each time we want Jenkins to start building a new branch, we go through all 7 multibranch project configurations and update this field to include the new branch.
It's a bit of a pain to go through each configuration and change this field every time, since we always want each configuration to have the same list of branches. Is it possible to simply use some type of a variable in this field? This way we only would need to change one location instead of trying to keep 7 different configurations in sync with each other, which is prone to error and also a bit of a pain.
Thanks for your help!
Allen
Rather than filtering with wildcards, you could try filtering branches with regular expression. In our case, pattern like:
(master|develop|release.*|feature.*|bugfix.*)
has been working well to cover the repository. That is, assuming that you follow Git Flow or similar methodology. Unfortunately, there is no simple way to sync the configuration between MultiBranch Pipelines build from one repository. Neither Multibranch Pipeline, nor Organization plugins are designed to work with Multiple Jenkinsfiles.
Also, you can try to sync only the branch configuration between Projects using Jenkins script console. Most of the Job configuration does not have to be set on Project level. For instance, you can create shared script (or shared library) to would be sourced by other jobs, to set the same job properties on each of them. See How do you load a groovy file and execute it for details.
if you want to use the wildcard you can provide like below:
In this example it will discover only qa and dev branch.
NOTE: You have to use "Discover branches" also with "filter by name (with wildcards)" behaviour.
I have a problem with getting Google's Repo, gerrit & Jenkins working together.
our setup:
we have a Repo build out of few git repositories, which are all on our gerrit server. Manifest is also there.
Workflow:
user do changes in few files which sits in different git repositories in the Rep.
user commit & push the changes to Code review.
Problem:
for each of the repositories, a separate gerrit code review is created.
For each of those code reviews, Jenkins is being triggered.
If the changes are inter-depended (which they usually do), the Jenkins build will fail, as it takes only the changes in one repository each time.
How do we make Jenkins/Gerrit co-op to get the full changes into one build (that will work)?
Thanks
The configuration described here is very problematic,
and is sure to cause you grief in the future as well.
In the long run, consider one of those paths:
Reduce dependency between the components to the minimum
(this is preferred)
Merge the code to a single repository
Meanwhile -
Make sure the verification-job (in Jenkins) checks-out the latest code from all the other repositories
(those that are relevant for building this change)
Make (non-breaking) changes to one repository at a time
(requires some planning, of course)
I have multi-configuration project in Jenkins. My git repository have different branches. For example:
dev
stage
bug/code1
feature/code2
etc...
I want to create different Post build tasks, Publish HTML reports etc for each branch.
What is the problem? I changed configuration for stage branch. All works fine only before Branch Indexing. After this process, custom configuration for each branch replaced by multi-configuration project. It means if I added specific task only for stage branch, after Branch Indexing task will be removed.
Multi-Branch Project Plugin says this:
Sub-projects appear to be configurable, but they will be overwritten
by branch indexing if you manually modify them. There is no clear way
to remove or hide the configuration option on sub-projects (except
maybe with project-based matrix authorization??), though version 0.1.x
of this plugin accomplished that via some trickery that is not
possible in newer versions.
So my question is: How I can create custom configuration for each branch? Or what is the best solution for this? Maybe I should create different projects for stage, dev branches?
Thank you.
We have the similar situation like you, more than 10 branches need to be maintained. Instead of using multi branch plugin, we use job dsl to create the jobs for each branch.
For example, hello_branch1, hello_branch2....
Inside our job dsl project, we save the different json config for the different branches. In your case, you can think we save the post build script, or report to be published....
This will make sure the generated jobs are standalone and will not affect each other.
Br,
Tim
We have a Visual Studio solution containing about a dozen class library projects. They're our team's main internal framework. In Jenkins we would like to automate the building of these projects as soon as a check-in is made, and also publish a new version to our local NuGet repo.
The problem: We would like to trigger the build by polling SVN at the class library level, e.g. ..trunk/OurSolution/OurCoreProject. Changes in one project should not trigger a build on all the other projects. But the checkout needs to be done one level higher, e.g. at ..trunk/OurSolution, and I cannot figure out how this can be done.
We've tried and contemplated a few solutions already:
Checking out at project level and then send the .csproj file to
MsBuild.exe instead of the .sln file. This fails because the project
expects a sibling folder named .nuget.
Looking into the Multiple SCMs
plugin, but it seems to mainly add the ability to use different SCM
providers in the same project(?) I would like to avoid adding this
plugin until I know it solves this.
Splitting all the projects up into separate solutions. Doesn't feel very optimal...
Is there a way to solve this in Jenkins? Have a missed any viable solution?
Yes you have missed something... the Advanced... button on the Subversion checkout configuration.
Do your SVN checkout on ..trunk/OurSolution
Click Advanced...
Under Included Regions, type ..trunk/OurSolution/OurCoreProject/*
For more info, click the ? icon next to relevant text area on the UI
If set, and Jenkins is set to poll for changes, Jenkins will ignore any files and/or folders that are not in this list when determining if a build needs to be triggered.
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.