Tag and check for release candidates

[pat-s]

fixes #60

• Creates RC tags in release()
• Aborts the build if the build is running in "state = release" and the sha of the most recent commit == sha of the most recent tag && "-rc" is found in the most recent tag name
• Deletes all RC tags in post_release()
• Uses gh (if avail) to merge a PR instead of merging the branch.

ToDo

• [x] Enumerate RC tags because we can have multiple rejections

[codecov[bot]]

Codecov Report

Merging #61 into prerelease-state will not change coverage. The diff coverage is 0.00%.

@@                Coverage Diff                @@
##           prerelease-state     #61    +/-   ##
=================================================
  Coverage              0.00%   0.00%            
=================================================
  Files                    17      21     +4     
  Lines                   184     531   +347     
=================================================
- Misses                  184     531   +347     

Impacted Files	Coverage Δ
R/api-bump-version.R	0.00% <0.00%> (ø)
R/api-finalize-version.R	0.00% <0.00%> (ø)
R/api-tag-version.R	0.00% <0.00%> (ø)
R/auto.R	0.00% <0.00%> (ø)
R/bump-version.R	0.00% <0.00%> (ø)
R/commit-version.R	0.00% <0.00%> (ø)
R/finalize-version.R	0.00% <0.00%> (ø)
R/gh-helpers.R	0.00% <0.00%> (ø)
R/state.R	0.00% <0.00%> (ø)
R/tag-version.R	0.00% <0.00%> (ø)
... and 8 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 19e1927...dedc3cf. Read the comment docs.

[pat-s]

@krlmlr Successfully used this branch to release mlr v2.18.0 including to failed attempt (which triggered two "-rc" tags).

[krlmlr]

I'm moving towards bumping the version with each attempted release. It's also recommended practice by CRAN.

[pat-s]

Not a friend of this practice.

Does this mean you do not want to merge this PR at all?

[krlmlr]

Numbers are cheap.

We might support both ways, it's low priority at the moment.

[pat-s]

I don't mind the numbers per se (I'd there is a need for a new release) but the inconsistency in news numbering (personal splean probably).

[pat-s]

Here's a snapshot how unleash("patch") looks like currently (using the tag_release_candidates_gert branch.

pre_release()

release()

post_release()

[pat-s]

Rebased and stripped the diff, not sure if I removed something important though.

I'd just check how it behaves in practice then but ofc this is your decision in the end.

[krlmlr]

/style

[krlmlr]

/merge

[pat-s]

Did your latest comment have the intention to merge this PR?

[krlmlr]

No.

[krlmlr]

/merge

[krlmlr]

I'm experimenting with a flow that allows seamless integration of the target branch into the source branch. I do wonder why GitHub hasn't implemented this yet. Anyway, this is now available through the "/ merge" command in pull requests. Because GHA won't run checks when I push directly, I open a PR instead so that the user can merge manually and trigger checks in the target branch.

CC @wael-sadek.

[pat-s]

@krlmlr How do you want to proceed here? I assume closing?

[krlmlr]

I'm open to discussing release candidate tags. About to merge that long-running PR, this will probably close this PR.