https://usethis.r-lib.org/reference/browse-this.html

From my docs:

Any downstream actions (such as this action!) can now use the prepared image, but they have to know its name.
The --tag=repo:latest part of the above call simply names your image, literally as "repo:latest".
It is very important you use exactly this name, because otherwise downstream actions (this action) cannot base their own work on it.
This isn't terribly elegant, but currently appears to be the only way on GitHub actions to identify images from past actions (see this issue).

Currently, the translation of R into the github actions subset of HCL is a pretty hacky and ugly mix of some unholy glue action and mustache/whiskers template.
Results look ok, but it's hell under the surface.

It'd be nice to migrate to some kind of official R2HCL pkg at some point, or maybe just R2TOML should do the trick.

pkgdown::build_favicon()

would be nicer to use a real check from some other pkg here.

tracked in r-lib/usethis#625

Currently, the action template diverges ever so slightly from the documented gh spec: the uses field is listed last.
This is done to avoid a triple } in the template.
A triple } causes mustache to fail thus:

Error in parseTemplate(template, partials = as.environment(partials),  : 
  Template contains unbalanced closing tag. Found: '/secrets}' but expected: '/secrets'

Replacing {{ with another delimiter does not solve this problem, because apparently the delimiter gets replaced before the whole thing is evaluated or something.
So you get the same error message with other delimiters.

Also, oddly, you don't get the same error at the beginning of the action, where there technically also 3 braces.

It's worthwhile noting that this is a bit of a special case, because the contiguous 3 braces occur because they serve as if clauses (known as false or empty lists in mustache).

Would be nice to fix this at some point, but mostly for cosmetic reasons.

Would be nice to save knitr caches (index_cache/) and other such build artefacts.

GitHub might either provide this out of the box at some point, or we might wait for some other service (action!) that we can save arbitrary assets to and retrieve on new runs.

Would basically mean a new action in between.

Might be related to offloading expensive computations to beefier (AWS etc) services.

These actually should be separate actions, because

1. they should run on (some yet to be chosen) vanilla image (not byod)
2. they should first parse and download the DESCRIPTION. We don't want people to have to specify the dependencies in the DESCRIPTION and their byod in this case. This (the parsing) may need some amount of bashing.

because that gives a better idea of what gh actions can do.
ideally with some kind of time lapse to make it quick

I guess this could be done, though if it were done systematically and rigorously that might be a lot of work.
We might just go with the gut feeling: seems pretty darn fast.

website firt has to be online
https://community.algolia.com/docsearch/

Not quite clear how this would work, maybe it's just a piece of documentation.
But it would be neat to have this, because you might kinda want the same streamlined CI/CD experience across all of your projects.

Kinda like what use_this::tidy_ci() does currently.

this is just a feature request

this would be an alternative / addition to #14.

This could be implemented as a "simple" testthat unit test.

1. There exist a bunch of boilerplate projects inside of the ghaction repo. (We can use the commonly used starter projects from RStudio for example).
2. Once the test gets run:

• the relevant boilerplate projects gets pushed to a (new?) repo on github.com (this might be possible inside of R using the git wrappers from usethis.
• with the currently templated version of .github/main.workflow.
• then the test waits for the github api (via gh::gh) to signal that the repo in question has successfully run through the action (or actually has failed on some of them, that we might also want to test!).
• then the test returns the appropriate condition.

The same test gets run on every commit inside of GitHub actions (meta), though that might require some more git auth.

Also, the tests would have to run in parallel, otherwise this would take too long.

Aaaand we should ask github first whether this violates their TOS, because we're kinda programmatically querying github actions.

https://github.com/jimhester/lintr

pasting the token is annoying.
instructons: https://github.com/jimhester/wercker-r-example

might be better if codecov just allows traffic from gh actions as they seem to do for travis and circleci

via https://usethis.r-lib.org/reference/browse_github_pat.html

it appears that currently, the image gets rebuild for byod every commit, which may in many cases be unnecessary.
It would be nice to cache byod images in this case.
It's unclear if/how gh actions might do this out of the box.

If they do, it's possible that we're polluting the builds with the entire repo content, and therefore (needlessly) invalidating the cache (because there's always something new in the repo, as per the commit).

If they don't it might be worthwhile to consider doing this as part of the rscript-byod action, though this would probably require storing and publishing the image outside of gh action which we initially wanted to avoid. Adds a lot of complexity and perhaps cost.

http://hexb.in/sticker.html

see e.g. https://github.com/actions/action-builder

https://github.com/nektos/act

expecting them as a character is awkward

it appears that gh actions is always re-downloading base images, which makes this pretty slow for a big image such as rocker/verse