Codeberg / Forgejo compatibility

[chrysn]

Context

As someone who avoids GitHub for private repositories, and is not really happy with the current practice of IETF documents being maintained here, I'm exploring alternatives. (GitLab is where some people including me already host drafts, but it is relatively complex to self-host, and has vastly different CI system). An attractive is Forgejo (eg. as hosted at codeberg.org), which has the upside of providing "forgejo actions" that are intentionally compatible with GitHub actions.

I've been exploring options in an issue of my latest draft repo, and while there is some way to go, I'd like to both track progress of any necessary changes to i-d-template here.

My expectation is that in the course of this effort, there would be pull requests that generalize detection of relevant URIs to recognize a wider variety of hosters, and possibly to be more explicit in places (for example, uses: martinthomson/i-d-template could need to be replaced with uses: https://github.com/martinthomson/i-d-template@v1). My hope is that those changes will come without undue increase of complexity here, and acceptable upstream. My ideal outcome would be that cloning i-d-template into a codeberg hosted repository would work on a Forgejo instance just as easily as on GitHub.

Open sub-issues

• Changes to the .github/workflows/* default files:
  • Any uses that don't go to established actions (of which a copy is maintained with possible compatibility adjustments on Forgejo) needs to point to its full URI, eg. s_martinthomson/i-d-template@v1_https://github.com/martinthomson/i-d-template@v1@.
  • There is currently no upload-artifact action. Next steps are to determine whether the binary files Forgejo can have as part of a release are sufficiently close to artifacts that there could be an upload-artifact action, or whether there is another artifact concept there, or whether that step can simply be skipped on Forgejo (I'm not sure which purpose it serves).
• default-branch.py would need to be adjusted (although setting DEFAULT_BRANCH may suffice -- any Forgejo hosted repository is new enough that it's likely to just use the new and hopefully long-term default name)
• Some places in the makefiles expect properties of GitHub that Forgejo also has (and just need more flexible parsing of remotes).
• Some places in the makefiles likely expect properties of GitHub that Forgejo does not have; these will need evaluation as to how critical they are (a reduced feature set, eg. going through make upload rather than expecting tag pushing would be OK for me, at least initially) and whether they can be made to work for both.

Directions

So far, there is nothing I'd immediately need from Martin and other maintainers here -- but if you think this is a a doomed activity to the point where you wouldn't even accept small alterations going forward, please let me know to avoid wasting time.

[chrysn]

To avoid altering components that would likely not be tested, I'd consider making some assumptions or requirements on the underlying repository for use with codeberg. Do these sound practical to you to assume? (Not sure whether support for them for GitHub based repos might at some point be deprecated).

• [ ] Branch name: default-branch.py depends a lot on GitHub API. Repos using codeberg are likely recent enough to assume that main is the default branch.
• [ ] setup-note.sh: New drafts often hav a venue: anyway. (easy enough to do in https://github.com/martinthomson/i-d-template/pull/399#issuecomment-1641665412)
• [x] (Items may be added later, I'll keep this post as a check-list of whether we'll go with that)