On 2019-05-07 19:12:00 +0000 (+0000), Penney, Don wrote:

I've learned a bit more this afternoon about how Gerrit updates Launchpad bugs based on the commit messages in reviews and thought I should share and clarify some things for folks.

As noted on the wiki:

https://wiki.openstack.org/wiki/StarlingX/CodeSubmissionGuidelines

if you're working on a Launchpad bug, you need to specify one or more tags in the commit message for Closes-Bug, Partial-Bug, or Related-Bug with the Launchpad bug number, such as:

Closes-Bug: 123456

We've also seen that it appears this tag must be in the final section of your commit message, ie. no blank lines following it... so the following is good:

This commit fixes the typos.

Change-Id: If46f03a5d042f949db9359d6ddd7f69790ccaf4f Closes-Bug: 1827326 Signed-off-by: Don Penney <don.penney@windriver.com>

whereas the following would appear to be ignored (I'm not sure why, yet):

This commit fixes the typos.

Closes-Bug: 1827326

Change-Id: If46f03a5d042f949db9359d6ddd7f69790ccaf4f Signed-off-by: Don Penney <don.penney@windriver.com>

If it helps, the Python script responsible can be found at https://opendev.org/opendev/jeepyb/src/commit/63f0ba511572149c41a9affebddb0e... which is called from a Gerrit hook script at https://opendev.org/opendev/system-config/src/commit/63dac37550bb695232f6cfd... any time a new patch is pushed. I don't know for sure that we necessarily enforce that matched footers actually appear in the final "paragraph" of a commit message, but that is where they are expected at least. I *do* know things will get weird on you fast if you put the Change-Id line somewhere other than the footer, so it's best to be in the habit of observing this common Git convention.

Two things will happen when the tag is processed correctly:

1. Gerrit will mark the Launchpad bug as "In Progress" (or different status for merged or abandoned, of course)

2. Gerrit will add a comment to the bug indicating "Fix proposed" ... BUT ONLY ON THE INITIAL PATCHSET

The note on that second point is important... If you do not set the tag correctly on the initial review creation, Gerrit WILL NOT add a comment linking back to your review. In which case, you should probably do this manually yourself. (I suspect this is intended to avoid adding a comment every time the review is updated.) [...]

Note that there is also a third action it performs on the initial push of a new change: assigning the corresponding bugtask to your LP account. This action requires the https://launchpad.net/~hudson-openstack account used by our script to be a member of that project's "bug supervisors" group (also the username likely gives you some idea of just how long we've been using that account!). If it's not, then all actions (including commenting) will be silently skipped for that event because the script ends up throwing an exception and bailing out early. Further, the script is also called on change merges (in which case it will comment and update the bugtask state to "fix merged"), and when the change is abandoned or restored. These actions will take effect as long as a bug footer is present in the commit message at that time, so even if you forget to add it with the initial push it's still a worthwhile addition once you do finally remember. -- Jeremy Stanley