fledge icon indicating copy to clipboard operation
fledge copied to clipboard

automation: dealing with rejections

Open pat-s opened this issue 3 years ago • 5 comments

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?

pat-s avatar Oct 01 '20 08:10 pat-s

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).

krlmlr avatar Oct 01 '20 08:10 krlmlr

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

pat-s avatar Oct 01 '20 09:10 pat-s

  • 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.

pat-s avatar Oct 02 '20 13:10 pat-s

I like this idea. I guess we can apply the changes from #61 directly on #28.

krlmlr avatar Mar 11 '21 09:03 krlmlr

Just noting that the "state" could be indicated by a PR label.

maelle avatar Apr 21 '22 12:04 maelle