Conversation
adamnovak
left a comment
adamnovak
left a comment
There was a problem hiding this comment.
This looks pretty good, although I'm not quite sure about the big blocklist of tags to never delete, and whether it does anything.
Also, do we care about whether we've told anyone to use a particular recent CI build to work around a problem with no released fix? As is, this script will delete even quite recent CI builds that people might be using. Maybe we shouldn't delete anything newer than the most recent real release?
|
|
||
|
|
||
| # more of a comment; this list really doesn't need to be updated since we filter by length. | ||
| whitelist = [ |
There was a problem hiding this comment.
This name could be a bit more descriptive, and I think the semantics are backward. These are the ones we always keep, and never delete, so we should call this ALWAYS_KEEP or IGNORED_TAGS or BLOCKLIST or something. The way it is now it looks a bit like these are the ones that the deleter is allowed to delete.
| non_release_minimum_tag_length = len('5.5.0a1-dce7a69af77da45c4ab1939e304ec92865ad9c57-py3.7') | ||
| if len(tag) >= non_release_minimum_tag_length and tag not in whitelist and dev_version: |
There was a problem hiding this comment.
Nothing in the list is as long as this minimum tag length; do we even need the list at all?
|
|
||
| if user_reply == 'y': | ||
| for tag in tags: | ||
| response = requests.delete(f'https://quay.io/api/v1/repository/{repo}/tag/{tag}', headers=headers) |
There was a problem hiding this comment.
If the list is meant to be a second safety interlock, maybe we should check against it here instead?
| tags.append(tag) | ||
| print(tag) | ||
|
|
||
| user_reply = input('\nDo you wish to delete these tags?\n\n') |
There was a problem hiding this comment.
This should have a (y/n), or someone will type yes or Y and be annoyed.
| tags = [] | ||
| for tag in response.json()['tags']: | ||
| tag = tag.strip() | ||
| dev_version = tag.split('-')[0].endswith('a1') |
There was a problem hiding this comment.
Are we ever going to actually release an a1 and get bumped to a2?
|
Hey @DailyDreaming, it turns out that #3781 (comment) wasn't happening because @jpuerto-psc pulled It turns out that It looks like our releases have been referencing themselves more or less forever through the full tag including commit information, and not via the short tags like So this PR should probably change Toil over to point to itself via the short tag, and we should find a way to restore the longer tags that point to release Toil versions and to skip over them when doing cleanup in the future. |
2 participants
I just deleted a few years worth of CI/CD cruft with this. We shouldn't need to run it too often, so I'm advocating for keeping this manual (maybe only running it when releasing a new version).
Changelog Entry
To be copied to the draft changelog by merger:
Reviewer Checklist
issues/XXXX-fix-the-thingin the Toil repo, or from an external repo.camelCasethat want to be insnake_case.docs/running/{cliOptions,cwl,wdl}.rstMerger Checklist