Release do-nothing script: correct handling of patch releases #6675
Conversation
![scitools-ci[bot]](https://avatars.githubusercontent.com/in/212324?s=60&v=4){kind=small}
| cls.get_github_user, | ||
| cls.get_release_type, | ||
| cls.analyse_remotes, | ||
| # cls.parse_tags, |
| for parts in remotes_split | ||
| ] | ||
|
|
||
| scitools_regex = re.compile(r"github\.com[:/]SciTools/iris\.git") |
There was a problem hiding this comment.
Remotes do not have to end with .git. Would it still be unambiguous enough without?
| self.wait_for_done(message) | ||
|
|
||
| message = f"Set {self.strings.branch} to Active, Hidden." | ||
| message = f"Set {self.version.branch} to Active, Hidden." |
There was a problem hiding this comment.
New RTD interface: we believe that branches never built before now have to be added using the Add version button.
|
|
||
| message = ( | ||
| "Confirm that pip install works as expected:\n" | ||
| "conda create -y -n tmp_iris pip cf-units;\n" |
There was a problem hiding this comment.
This Conda environment will obviously be the latest version of Python. Sometimes Iris is incompatible with the latest version while we work on updating it; if we have added a Python max pin into pyproject.toml then Pip will detect this and refuse to install Iris into this environment.
So a note needs to be included that the developer should potentially include the appropriate Python pin when creating the Conda environment.
There was a problem hiding this comment.
Potential extra work! Attempt to install with the latest version of Python to prove that the pin works, then attempt to install with the correct version.
| "The new release will now undergo testing and validation in the " | ||
| "cf-staging channel. Once this is complete, the release will be " | ||
| "available in the standard conda-forge channel. This can " | ||
| "sometimes take minutes, or up to an hour.\n" |
There was a problem hiding this comment.
Should consider moving some steps to fill the conda-forge wait. Definitely RTD. Possibly some other post-release steps (although I'm cautious about things like posting an announcement until conda has finished).
| return self.Strings( | ||
| series=series, | ||
| branch=series + ".x", # v1.2.x | ||
| release=self.git_tag[1:], # 1.2.3rc0 |
There was a problem hiding this comment.
This needs to still be a thing - can't use self.release.public like I have tried to do (that includes the v).
| ) | ||
| self.wait_for_done(message) | ||
|
|
||
| if self.first_in_series: |
There was a problem hiding this comment.
This logic is fine, but first_in_series is flawed - it is written assuming that the release hasn't been cut yet, and the merge-back step happens post-release. Since the list of releases is refreshed every time, first_in_series will return False as soon as the first release has been cut, preventing this block from being entered.
| f"git add {self.whats_news.index.absolute()};\n" | ||
| 'git commit -m "Restore latest Whats New files.";\n' | ||
| f"git push -u origin {working_branch};" | ||
| f"git add {self.whats_news.index_.absolute()};\n" |
There was a problem hiding this comment.
The git add for latest.rst is too early - the script suggests subsequent edits, without adding again.
| f'git commit -m "Recipe updates for {self.version} .";\n' | ||
| f"git push -u origin {self.version};" |
There was a problem hiding this comment.
We would benefit from a warning about what happens if you push directly to upstream - it prompts an immediate release without any pull request.
There was a problem hiding this comment.
Perhaps we could get the user to explicitly input the name of their fork remote, at the same time as warning them.
1 participant
🚀 Pull Request
Description
To-do
nothingfor testing the do-nothing scriptiris/tools/release_do_nothing.py
Lines 22 to 29 in bb248bc
series, which is meaningful to everyone while not being ambiguousConsult Iris pull request check list
Add any of the below labels to trigger actions on this PR: