Arvados

Ready for review at commit:96f272678908e3cba4466d924921e5037675ba94 on branch 18300-release-ticket-association in repository arvados-dev.

If I understand correctly, what this does is:

• Starting from a tag, go through the whole history of commits that contribute to that tag, and mark them all as "excluded"
• Starting from another commit (e.g. HEAD) go through the whole history of commits that are not already "excluded"
• For every merge commit, find a reference to a redmine ticket number
• Go through all the ticket numbers and assign them to the release

Peter Amstutz wrote:

If I understand correctly, what this does is:

• Starting from a tag, go through the whole history of commits that contribute to that tag, and mark them all as "excluded"
• Starting from another commit (e.g. HEAD) go through the whole history of commits that are not already "excluded"

Yes, this is the equivalent of e.g. `git log 067a68b5e9dfa1c7d5e68fd64553e0ced89cad36..HEAD`, where 067a68b5e9dfa1c7d5e68fd64553e0ced89cad36 is the tag for the 2.3.0 release.

• For every merge commit, find a reference to a redmine ticket number
• Go through all the ticket numbers and assign them to the release

Yes, but only if they have not been assigned yet to another release.

By default the user is prompted with details for each issue found that is not already assigned to the desired release and given the choice to assign it to the release or not. This happens when the issue is not asssigned to a release yet, and when it is assigned to another release.

There is also a cli flag to assign unassigned tickets to the release without prompting.

A dry run mode would be nice.

But, I was able to use it to collect and assign tickets to 2.3.0 and 2.2.2, so it definitely works. LGTM!

Peter Amstutz wrote:

A dry run mode would be nice.

But, I was able to use it to collect and assign tickets to 2.3.0 and 2.2.2, so it definitely works. LGTM!

Thanks, merged!