[Starlingx-discuss] FYI: Linking commits/reviews to Launchpad bugs

Jeremy Stanley fungi at yuggoth.org
Wed May 8 21:00:23 UTC 2019

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 at 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 at windriver.com>

If it helps, the Python script responsible can be found at
which is called from a Gerrit hook script at
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"
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20190508/6f6a2de6/attachment.sig>

More information about the Starlingx-discuss mailing list