Adding `usethis::use_forgejo_action` support for Codeberg / Forgejo Actions

[dgkf]

This is a bit of a follow-up to #2102

For some background, Codeberg is a recent popular GitHub alternative and runs on a backend called Forgejo and they have their own Actions tooling that can accommodate most GitHub Actions. In the future, there might be other "forges" that spin up using Forgejo, and their goal is to have a less centralized coding ecosystem.

Supporting Forgejo Actions is quite similar to supporting GitHub Actions. In fact, Codeberg (Forgejo) can almost use r-lib/actions out of the box. I kicked off a repo to make the necessary edits over in codeberg.org/r-codeberg/r-lib-actions.

Would there be interest in setting up usethis::use_forgejo_action (+maybe usethis::use_codeberg_action aliases) as alternatives to usethis::use_github_action? The repo structure is a direct mirror of r-lib/action so it should be as simple as swapping out the repository url where the yaml file is fetched from. In the future we may have some additional example workflows that better align with Codeberg's more resourceful approach to runners, but for now it's one-to-one.

Just wanted to gauge interest before I put in the time to make the changes and open a PR.

[jennybc]

Below is the saved reply for "this is too far from our workflow", which comes up periodically here in usethis. I think this is sort of thing you'll need to do in a separate package or a fork. Although it's negative, I wanted to give you a quick, straightforward reply. Thanks for checking in.

---

This seems like an interesting idea, but we (usethis maintainers, tidyverse/r-lib team) don't currently use THING Codeberg and Forgejo ourselves. Our experience adding usethis features that we don't use personally has not been good. These features are especially vulnerable to bit rot, since we won't notice problems in a timely manner and we lack motivation and context when work is needed. This can then lead to a negative experience for new users.

Thanks again for the suggestion, but we've learned everyone is better off if we identify a lack of fit in advance.

[dgkf]

Totally understand the hesitation. Maybe I can propose another solution, then! It sounds like you need a maintainer who actively uses non-GitHub tooling (me! 🙌).

Okay, maybe on the surface that doesn't sound so different from me just kicking off a separate project.

However, I think that visibility is important and r-lib/tidyverse has enormous reach, producing a lot of great content that is often perceived as "the right way" to do development for a lot of people. For example, Hadley's "R Packages (2e)" points to usethis as the singular tool for development setup. For most budding developers, any expectations about what is "the right way" are being crystalized at that point in the book. Relegating these tools to a separate package only reinforces a perception that GitHub alternatives are not serious alternatives, which I think is quite stifling for the diversity of the R ecosystem.

And just to add some credentials,

• I maintain codeberg.org/r-codeberg
• I have a history of contributing bug reports and code to remotes (remotes#628, remotes#608) and now pak (pak#791, pkgdepends#353, pkgdepends#355) to support GitHub alternatives

Anyways, I'll leave it there and won't push the topic any further. I appreciate your consideration.