HOWTO organize build of the releases

[yarikoptic]

To be implemented after #7 is merged

This is just an idea, somewhat inspired by how conda-forge does it. @jwodder please share your thoughts on either sounds like a good way to proceed or you see better setups?

build

• all release builds will come (be done) in PRs
• introduce a file, e.g. build.yaml to reside in the top directory, which would say which release (tag) to build (could be just version: .... to start with; want to have it structured format so we could extend its schema to fit desired needs in the future, e.g. build different versions for different architectures, add build index etc)
  • well, in principle we could (ab)use README.md for this purpose but I felt that we better not
• modify build workflows to check if they are triggered by PR and either build.yaml was modified in that PR, and if so -- instead of building upstream/master, build the commitish (well - tag) specified in build.yaml. We also make them on changes to that file (not just on the workflow itself).

automagically trigger

• update-mirror.yml would either detect a new tag fetched, or check if any version tag is >= the one in build.yaml. If new version is detected, it will modify build.yaml and send a PR with that change. If multiple new versions detected would send PR for the "latest"

[jwodder]

I think build.yaml would be easier to query & update if it were JSON instead. Other than that, the plan seems fine.

[yarikoptic]

yeah, I guess with jq might be easier indeed. But there is (python based) https://kislyuk.github.io/yq/#installation , so should be as easy. Or what particular aspect for query/update am I missing?
In general I do not care much -- could be json -- but just that all the rest is yaml, so uniformity would be of benefit here.

[yarikoptic]

ok, missing piece -- apparently there could be "inputs" for a workflow which is triggered upon workflow_dispatch. So we could probably use that feature to make workflow parametrizable and triggered for any specific build?

[yarikoptic]

@jwodder please look into making git-annex build parametrizable via inputs specification (on what committish of git-annex to build), I feel like that should be the way forward on this (not yet sure about separate badges etc as in #9 )

[yarikoptic]

now that #11 is merged, we just need to adjust the .github/workflows/update-mirror.yml to trigger that workflow for every freshly fetched git-annex tag release (I guess grep -E '^[0-9]+\.20[0-9]{6}(\.[0-9])?' is to match), right?

[yarikoptic]

i.e we would not even bother with PRs for now? (although I would have liked it to be PRs with corresponding workflow results attached, but I guess it would be more complicated, unless you see it doable without much sweat @jwodder )

[yarikoptic]

I guess for now we can consider it closed by #12