True, change-related variables on a regular branch are not set.

That is due to the fact that Gerrit doesn't know what is the associated change because the branch is not pointing to a change ref.

Jenkins is typically used with Gerrit for allowing pre-commit validation. What is your use-case on a regular branch?

That's right.

My use case: 

• We produce a docker image for our repo on every commit and push it. For pre-submit commits, we tag it with the commit hash and the Gerrit change number. For post-submit we also does, alongside we also tag as :latest. In the end of the pipeline, we post comments on the change (gerritReview step) with a snippet for the docker pull command of that image matching the revision of the patchset. 

This comment is useful to be posted also for post-submit commits, due to the fact that the commit author can have the image name of that desired commit without having to search (not every time the last patch-set (after hitting Submit) is the same of the latest one after pushing, because it gets rebased).

However, there is another possibility the lack of these variables is depriving me:
I want to tag my docker images with the Gerrit change number even after it gets merged, and for this I need the variable GERRIT_CHANGE_NUMBER and/or GERRIT_PATCHSET_NUMBER to be set.

So far I have not found any no workaround.

If we want to get those variables, we need to try to understand what is the change associated with a SHA1: it is feasible I believe, because Gerrit would be able to find the change number based on the SHA1 of the commit.

Changed the issue to improvement and will put it in my backlog.

Thanks for sharing your use-case.

The approach you suggested makes a lot of sense. I might try to contribute to the code, I will have a look when I get some time. Thanks!

felipecassiors,

You mention triggering the 'master' branch when a change has been submitted to it.  Do you mind sharing how you managed this?  My gerrit webhook plugin is sending all events to Jenkins but master job remains untriggered... I expect that the master branch should be triggered on a 'ref-updated' event since it's head is changed once a change is committed to it - is this correct?

As an alternative I wouldn't mind triggering the change job instead (which should happen by the 'change-merged' event) but it seems the change jobs are automatically closed and disabled as soon as the change is submitted.

felipecassiors, Nevermind, I had only the refspec configured for changes (+refs/changes/:refs/remotes/@{remote}/) and not normal branches (+refs/heads/:refs/remotes/@{remote}/)

I also need information about the merged change in order to facilitate the promotion of reviewed packages.  i.e. once a package built from a change has been verified, reviewed and 'submitted', I want it to be moved to another repository to show the increase in maturity level.  I think this is a pretty common flow in modern CI