Versioning GH actions

[gaborcsardi]

It seems like usethis always uses the v1 tag of the actions repo, which was fine until now, but I am about to update the setup-r-dependencies action and the related example workflows that use it in a way that might not be backwards compatible.

So I would create a new branch for this (or just use main?). For a short time this branch would live as the "devel" workflow, and then we will make it the default, and then r-lib/actions will receive a v2 tag.

So it seems like it would make sense to support multiple tags/branches in usethis as well. usethis could pick up the latest release / tag from the r-lib/actions repo, this could be the default.

[jennybc]

How do you envision usethis discovering the default ref from r-lib/actions?

This will be a fairly easy adjustment, since all the workflow-downloading functions now route through use_github_file(), which already has a ref argument.

[gaborcsardi]

usethis could pick up the latest release / tag from the r-lib/actions repo.

[jennybc]

Yeah I meant ... latest in terms of the date modified? Or latest in an alpha/numerical sense? I mean, there's only one now, but ...

library(tidyverse)

(out <- gh::gh("/repos/r-lib/actions/tags"))
#> [
#>   {
#>     "name": "v1",
#>     "zipball_url": "https://api.github.com/repos/r-lib/actions/zipball/refs/tags/v1",
#>     "tarball_url": "https://api.github.com/repos/r-lib/actions/tarball/refs/tags/v1",
#>     "commit": {
#>       "sha": "f349d3ebc6fc46a3731c7c6c968105fde299bcb3",
#>       "url": "https://api.github.com/repos/r-lib/actions/commits/f349d3ebc6fc46a3731c7c6c968105fde299bcb3"
#>     },
#>     "node_id": "MDM6UmVmMjE0MjE1NTI0OnJlZnMvdGFncy92MQ=="
#>   }
#> ]
map_chr(out, "name")
#> [1] "v1"

^{Created on 2021-12-06 by the reprex package (v2.0.1.9000)}

[gaborcsardi]

Sorry, yes, we would order the numbers. I don't think we would have real semantic version numbers, so just removing the v and then ordering the rest numerically seems good?

[jennybc]

OK, sounds good.

[jennybc]

I'm beginning to question defaulting to the latest tag in r-lib/actions, in a version number sense.

Because, for example, right now that might deliver the not-yet-quite-official v2 to people who probably want v1. And you can imagine the same cycle repeating itself in the future whenever there's a need to start experimenting with v3.

@gaborcsardi Do you think there should be some other mechanism (tag, probably, e.g. released) for designating the version that's currently considered the best for most users?

[gaborcsardi]

Aren't pre-releases marked in the API?

[gaborcsardi]

gh::gh("/repos/r-lib/actions/releases")

...
    "node_id": "RE_kwDODMSrZM4DSp0x",
    "tag_name": "v1",
    "target_commitish": "master",
    "name": "v1",
    "draft": false,
    "prerelease": false,
...
    "node_id": "RE_kwDODMSrZM4DSVjI",
    "tag_name": "v2",
    "target_commitish": "master",
    "name": "v2 ",
    "draft": false,
    "prerelease": true,
...

So we can choose the latest release that is not a pre-release.

[jennybc]

Also, do you think the .yaml should contain a comment re: which r-lib/action ref was used? Either baked into it on the r-lib/action side or incorporated by use_github_action_*(). My motivation is to help people know which version they currently are using.

[jennybc]

Aren't pre-releases marked in the API?

I thought we were going to consult a generic tag. But OK yes if we're talking about releases, I see how it will work.

[gaborcsardi]

Yeah, it would be nice to include the source, sure. If you want a proper reference, that would be the sha, because the tag will change. But maybe the tag is enough.

[jennybc]

Just FYI I think part of my confusion with how this is going to work in practice stems from the fact that, I think, the v1 tag in r-lib/actions has previously just been a tag, not a release.

Re: including the source, I suppose it might make sense to record the ref and, assuming it's not already a SHA, also the SHA.