Closed sirosen closed 2 years ago
I think this whole issue is somewhat off-base, in retrospect. We've started using scriv
, and I don't see a good workflow here.
I think stubbing in some macro-text in your fragments and then replacing it later is the only thing that could work. It just seems super-fragile and not very much worth it. If you really want links like that, probably just use towncrier or something.
Very often, we want to link to issues and PRs in our changelogs. This provides a good way to look up the specifics of a change when the exact meaning of the changelog entry is unclear.
For issues, it's very simple: put a link area into your fragment template. Done! ✅
But what should you do if you want to link to a PR (or, to be less github-centric, MR)? This flow depends upon the PR already having been opened. I wonder, could
scriv
be able to find this info atcollect
time? It would have to be able to call some hook (maybe one which I write, as a user initially, and then later something as a pre-set option?) to look at the GitHub API.I'm thinking about this, and also about potentially putting some string into the fragments themselves, like
SCRIV_PR_LINKSTUB
, which can then be replaced via some bot user in GitHub Actions.Is there a role for
scriv
in this process, if only to provide guidance on this in the docs?