chrysn
commented
12 months ago I think I've addressed my own concerns by 1. taking the pattern already established in wg-meta.sh (no need for a function call here, the variables are populated at sourcing time), and 2. applying this to get the old "GitHub" text as a hostlabel that is looked up based on the git host.
The only remaining differences a make -B -f lib/setup.mk now produces to my working repo are
- changes to .github/workflows/ghpages.yml (which I think I'll want to refactor into standalone actions; in particular, token access for pushing to pages is set up vastly differently; then all that's left is full-URI
useslines and setting CI_HAS_WRITE_KEY=true) - the addition of an "or under BSD-3-clause" to license and contribution file (which is necessary for code on Codeberg), which I guess will need to be maintained manually for some time (ie. until I know what's happening first -- moving to a different Forgejo instance or more people than me using it).
Following up on #399
(which to my knowledge I can't indicate to GitHub in a way that it only shows the commits after "Support non-GitHub hosts for .note.xml generation")[edit: A force push of a fixed commit message after 399 was merged did resolve this], these are changes that'd make using Codeberg & co easier,but they'll probably need some rework after discussion.As before with #399, I'd like to leave this sit for some time until I request review (while still having it available for the curious).
Prominent points I'm not too happy with are:
The changed setup-readme.sh more or less copies over (and extends) the big per-host switch that is already in build-index.sh. I suppose having a script like wg-meta.sh would be the place to outsource this?[edit: Now doing something very similar to wg-meta.sh in host-meta.sh]Existing output is changed where GitHub is replaced with github.com. If 1. is properly resolved, there could be a host label that'd be used in its place.[edit: There is now a hostlabel variable generated for known hosters]