[storyboard][release][help] Anyone interested in adding bug-closing logic ?
A long time ago, I wrote some Launchpad/release code so that when a
release is tagged, automation would go through the commit messages and
post a message on Launchpad bugs that are mentioned in a "Closes-Bug:"
stanza in the commit message of the changes corresponding to the release.
This functionality is missing for StoryBoard-driven projects. We'd need
something similar, that detects "Closes-Story:" stanzas and calls a new
With more and more projects being migrated to StoryBoard, would there be
anyone interested in writing that missing link ? It should be mostly
straightforward, the only obvious difficulty being storing StoryBoard
credentials for a release comment bot on the infra side.
It sounds like a great way to experiment with the StoryBoard API :)
So... Anyone interested ? Please ask me (or dhellmann) on
#openstack-release if you have questions...
Re: [storyboard][release][help] Anyone interested in adding bug-closing logic ?
On 2017-06-13 15:59:16 +0200 (+0200), Thierry Carrez wrote:
> This functionality is missing for StoryBoard-driven projects. We'd
> need something similar, that detects "Closes-Story:" stanzas and
> calls a new storyboard_add_comment.py script.
Probably not quite like that. StoryBoard itself considers any story
with only merged or invalid tasks to be closed, but stories simply
have an inferred active/closed status which can't be directly
The Gerrit its-storyboard plugin recognizes two commit message
The behavior it has is that it will leave a story comment for the
first and will auto-adjust the status of the second. The reason for
this design is that the "story" footer acts like our current
"related-bug" footer does with LP, while the "task" footer addresses
the additional steps we get from "closes-bug" today (though since
tasks are globally unique, a future optimization may be to make
"story" optional when "task" is provided and then infer stories from
tasks). The existence of "partial-bug" is seen as an LP-specific
workaround which SB doesn't need since stories can be made up of
Since a story can have tasks whose corresponding commits merge in
different releases, what I would personally expect from the release
tooling is to look at task footers and then add a "task note"
indicating the release in which that task reached merged status. If
we want to add a "released" task state in SB (that should be a
fairly trivial addition I think), then it could switch the state on
the task to that at the same time.