Release script milestone automation

[fao89]

[noissue]

[pulpbot]

WARNING!!! This PR is not attached to an issue. In most cases this is not advisable. Please see our PR docs for more information about how to attach this PR to an issue.

[fao89]

Currently validating milestone at release script:

pulp_file on  milestone [$] via 🐍 v3.8.0 (venv) 
❯ python .travis/release.py patch --lower 3.3 --upper 3.5


Redmine stats: {
  "project_file_support": [
    6653,
    5998,
    6885
  ],
  "without_milestone": [
    6653,
    5998
  ],
  "status_not_modified": [
    6885
  ],
  "milestone_1.0.1": [
    6885
  ]
}
Traceback (most recent call last):
  File ".travis/release.py", line 86, in <module>
    asyncio.run(validate_redmine_data(redmine_final_query, redmine_issues))
  File "/home/faguiar/.pyenv/versions/3.8.0/lib/python3.8/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/home/faguiar/.pyenv/versions/3.8.0/lib/python3.8/asyncio/base_events.py", line 608, in run_until_complete
    return future.result()
  File ".travis/release.py", line 61, in validate_redmine_data
    raise RuntimeError("\n".join(error_messages))
RuntimeError: One or more issues are not MODIFIED [6885]
One or more issues are not associated with a milestone [6653, 5998]
Verify at https://pulp.plan.io/issues?set_filter=1&status_id=*&issue_id=6653,6885,5998

[fao89]

Need to set this var on travis

[daviddavis]

Can you change it to REDMINE_API_KEY. I think this is what we're calling it in pulp-ci.

[fao89]

Sure!

[daviddavis]

This looks good overall.

RuntimeError: One or more issues are not MODIFIED [6885]

This brings up a good point: issue 6885 was released in 1.0.1 but we're not removing the changelog entries for changes cherry picked to z-releases. Perhaps we should? Or maybe we can just check that issues are at MODIFIED+?

@bmbouter @dkliban any thoughts? also, can we get a second review?

[bmbouter]

How would folks feel about using https://python-redmine.com/ instead of raw aiohttp requests?

[fao89]

I didn't do it before because I thought it would require to use the token, as we run it locally it would not be cool. But now I tested it, and for fetching issues, it doesn't need the token. So I'm +1 to it, it will make the code simpler

[bmbouter]

This brings up a good point: issue 6885 was released in 1.0.1 but we're not removing the changelog entries for changes cherry picked to z-releases. Perhaps we should? Or maybe we can just check that issues are at MODIFIED+?

When things are cherrypicked, I would prefer that both the z-stream, e.g. 1.0.1 and the next y-stream 1.2.0 changelogs would show the same entry. My thinking is that not everyone received the z-stream release so when users skip 1.0.1 they wouldn't see the bugfix listed. I'm comfortable with also removing the changelog from the next y-stream changelog if folks think that is better.

In terms of the Redmine issue for a bugfix, it's milestone can be set to the "first one released". So if that's a z-stream then its milestone can show that z-stream number. If that's a y-release then it can show the y-release number.

Having the machinery ignore issues already at a CLOSED state I think is fine.

[bmbouter]

Thanks @fao89 ! This looks good enough for us to give it a try!