2

I want my code review job to ignore changes that came from other Jenkins job, like my release job for example. Those commits can be identified either by the committing user (preferable) or the commit comment string (also acceptable).

Basically I have the same problem as the user who asked Ignore Jenkins job if commit message starts with a given string, except that I'm not using the Git plugin with polling. Instead I'm using the Gerrit Trigger plugin, which gets triggered on each new change set.

I believe the below screenshot includes the relevant configuration of the GT plugin.

I have searched around the web, but I couldn't find how to accomplish this. I found this kind of configuration for the Git plugin, but I can't use it since we're using Gerrit and so we need pre-commit changeset triggering rather than polling.

Trigger on "Patchset Created", "Draft published"

Community
  • 1
  • 1
Jolta
  • 2,620
  • 1
  • 29
  • 42

3 Answers3

3

Gerrit Trigger provides a group of variables in which you can find committer's name, commit message, etc. The solution I'm using is to test the values of these variables and end the build job if the test passes. But there might be a problem if you are using Jenkins V2.3 or later. Some of the variables cannot be accessed via $ in shell. You can refer to Jenkins V2.3 release notes to solve this issue. You could press the question mark right to Gerrit event to see the list of variables.

ElpieKay
  • 27,194
  • 6
  • 32
  • 53
  • You mean, to run these checks as custom shell commands, using Build Step -> Execute Shell? – Jolta Jun 14 '16 at 10:49
  • 1
    @Jolta yes. And the fetch and checkout part could also be done via shell commands. Therefore you can test first and then decide whether to do the fetch and build. Even if the job itself is triggered, it takes only a little time to run the test part. – ElpieKay Jun 14 '16 at 11:00
  • I see. Well, in that case I think I prefer using the "ci skip" plugin, since at least then I won't have to write any scripts myself. =) – Jolta Jun 14 '16 at 11:11
  • Another question, if a script is used to determine if the build should happen or not, how should the script control whether the build continues or not? I don't want the script to "exit 1", which would cause the build to fail. Must be able to separate failed builds from builds that "didn't happen". – Jolta Jun 14 '16 at 11:18
  • 1
    Maybe something like `if [[ "$test" = "bypass" ]];then echo bypass build;else echo build starts; #build steps or build script runs;fi`. You could write `#!/bin/bash -el` in the first line. `exit 1` could be in the build steps or build script. So the test part will not fail the job but the build steps could. But of course, you must make sure the commands in the test part will not return any error code which fails the job. – ElpieKay Jun 14 '16 at 11:27
  • OK. I would prefer not to see a red ball for a normal condition like this, so this approach seems less useful than the "ci skip" plugin in my own answer. – Jolta Jun 14 '16 at 12:52
2

One suggested approach was to use the "ci skip" plugin.

I set up my release jobs to include [ci skip] in their commit messages.

When using it I found it actually still triggers a build. However, the build is exited as "Not Built", just after checking our the commit. This means the build still clutters my build history, and it still consumes resources to fetch and rev-parse etc, so it is a less preferable solution to me.

While this solves my immediate problem, I will happily accept other answers since I'm not entirely happy with this one.

Jolta
  • 2,620
  • 1
  • 29
  • 42
  • Is it possible to split your release job into an upstream job and a downstream job? The upstream does not fetch and checkout, just test. If stable, the downstream is triggered to fetch and checkout and build. – ElpieKay Jun 14 '16 at 10:24
  • Interesting idea, but not sure I understood it. On what would the upstream job trigger? And on what would it run tests, if it hasn't yet built the software? – Jolta Jun 14 '16 at 10:51
  • the upstream is triggered by gerrit trigger. The test here, I mean, is to check if the commit should be ignored and if the build part should be bypassed. – ElpieKay Jun 14 '16 at 11:03
  • Aha. In that case, I would still get one started build of the upstream job for each commit, but not for the downstream job. There would be a slight time savings in not having to fetch the commit (good), but I don't know if it would be outweighed by having to trigger a second jenkins Job or not. Anyway, the added complexity of two jobs instead of one might make this undesirable. The downstream job has to have all the information from the upstream job in order to submit its "verify +1" on the triggering patch set. Not sure if the Gerrit Trigger plugin will support this? – Jolta Jun 14 '16 at 11:14
2

Actually, you can skip job execution using regex pattern in Gerrit topic configuration.

For example, you may not allow triggering job for change which topic has WIP word. This is possible using following regex ^((?!WIP).)*$.

Here is an example how it trigger is implemented in our pipeline

Gerrit trigger configuration:

enter image description here

Hope it will help.

aMJay
  • 2,215
  • 6
  • 22
  • 34
Name Placeholder
  • 36
  • 3