fledge
fledge copied to clipboard
automation: dealing with rejections
Sometimes packages are rejected for reasons that are not picked up by rhub or CI runs (example: URL changes from http -> https).
In this case, check_release_state()
switches back from "submitted" to "ready-to-release". However, no immediate release is desired because some fixes are necessary.
How do we detect this special case?
We could tag release candidates with a vx.y.z-rc-x
tag instead of relying on ./CRAN-RELEASE
, and check if we are on a rc tag. The tag should be set only after confirming the submission, we also need a manual way (in case submission fails).
This could be an option.
With mail automation, we could rely on the categorisation: if the most recent mail for the given version is a "rejection" (release()
checks this), unleash()
only continues if XYZ...
categorize_mails("mlr")
# A tibble: 4 x 5
type date package version id
<chr> <chr> <chr> <chr> <chr>
1 rejection Thu, 1 Oct 2020 09:41:06 +0200 mlr 2.18.0 174e31b6c52a6b62
2 manual inspection Wed, 30 Sep 2020 22:06:49 +0200 mlr 2.18.0 174e09fcb83a95ca
3 upload confirmation Wed, 30 Sep 2020 21:27:17 +0200 (CEST) mlr 2.18.0 174e07bcd2f6a07c
4 submission Wed, 30 Sep 2020 21:15:04 +0200 (CEST) mlr 2.18.0 174e0709580f8a51
- Tag release candidates in
release()
- When a rejection happens, state switches automatically from "submitted" to "ready-to-release" (because the package is not anymore in the incoming queue). When we are not ahead of the RC tag, no release is issued.
- Delete RC tags in
post_release()
- The next run to
release()
needs to force-tag as the current release version tag already exists
This also means that the next upcoming push will trigger a new release and should contain all necessary fixes.
I like this idea. I guess we can apply the changes from #61 directly on #28.
Just noting that the "state" could be indicated by a PR label.