On 3/7/22 09:22, jimsearle wrote:
Thanks, appreciate the response. Sorry if my terminology is not correct as I am still pretty new to Gerrit. We do have many times where someone will do multiple commits for different reasons, then do one publish to regress all those distinct commits together. This generates a patchset-created for each changeset, and the last changeset will include the commits for all so we only want the regression to run for the last one. I understand why Gerrit does this, just looking for an elegant way to avoide this. I know the --amend can be used for adding to a current commit, but it's not always used.
That sounds like the Gerrit server definition doesn't have the following options configured on it:
Build Current Patches Only Abort new patch sets Abort manual patch sets Those three options will basically get Jenkins to do what you're expecting. They're set by going to: Manage Jenkins -> Gerrit Trigger -> Cog wheel of the Gerrit serverThe options are just above the 'Test Connection' button of the configuration screen.
Currently I running a script to grab the get-related-changes via the
REST interface, then use a when expression in the pipeline to skip the
regressions if it's not the last commit in the chain.
On Monday, March 7, 2022 at 12:19:28 AM UTC-8 ice...@googlemail.com wrote:
jimsearle schrieb am Freitag, 4. März 2022 um 21:41:56 UTC+1:
Hi,
We have been longtime Jenkins user and recently started the
transition to Gerrit.
The Jenkins Gerrit trigger kicks off the job for each commit
that is in the publish, but we would prefer just to run the job
on the last changeset which includes all the commits. This
seems like it would be a common thing and available in the
configuration somewhere but I can't find anything.
Your terminology is a bit unclear, so I'll try to translate it to
typical gerrit terms:
In gerrit you have changes (also called changesets) that are a
single commit. So running a job for each commit is normal (in the
gerrit world).
=> this is trigger 'patchset-created'
Note that updates to such a change are done by amending the local
commit, not by adding another commit in series and then pushing
again to gerrit.
This gives a new patchset on the change. A change in gerrit is
fundamtentally different from a pull request in the github/gitlab
world.
Once all votes are in placesuch a commit can get "submitted" =>
merged to it's branch.
==> trigger: change-merged
So I would say gerrit trigger behaves as expected...
Björn
I can describe in more detail if this description is not clear.
Thanks,
Jim
--
You received this message because you are subscribed to the Google
Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-users+unsubscr...@googlegroups.com
<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/aad98aff-a66e-406a-9769-4903a77d091en%40googlegroups.com
<https://groups.google.com/d/msgid/jenkinsci-users/aad98aff-a66e-406a-9769-4903a77d091en%40googlegroups.com?utm_medium=email&utm_source=footer>.
-- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ce46c257-6a3f-1182-51f7-b4c7fe73eeae%40gmail.com.
OpenPGP_signature
Description: OpenPGP digital signature
