jeliasson
commented
2 years ago @thedavidprice Intresting! For deployments done thru GH, I don't see any big issues of having the canary version shown and updated in the README. Some jq to fetch the version from package.json file(s), update the README (using placeholders? hmm 🤔) and then use e.g. action EndBug/add-and-commit to just commit back those changes to the repository. I use that in my deploy repos. One thing that can be tricky of committing back changes is if there is many concurrent workflows that does this as the same time, as there is a slight risk of one being out-dated and thus failing when pushing.
Another approach could be that the respective workflows outputs and commit back their own file (e.g. ci/vercel.json that would contain the version) and then you'd have a separate workflow that is responsible for generating the README on interval, and just include those files containing various data.
For deployments outside GH.... maybe a webhook somewhere that do pretty much the same thing as described above; it expects a provider, a version and a authentication key (as we would like to keep our webhook protected) and it would then update those files in the repo. I do however recognize that there is some work to do this properly.
Food for thought
Inspired by #102
@jeliasson You gave me an idea! Can we add the Redwood canary version being deploy as well? All these projects are on the same canary, which is not always exactly aligned with latest canary (e.g. might be an hour out of sync).
Now that I write it down, I'm not sure how it would be possible outside a GH Action to update README, which would trigger deploys on Jamstack providers... Maybe not worth it.
And/or what I want to display is something like this: https://github.com/redwoodjs/deploy-target-ci/blob/b79a388fbe6dfab4b87dfe3f4933db53a30d7b40/vercel/package.json#L11
But for the main branch — does this work? And will it stay updated? https://github.com/redwoodjs/deploy-target-ci/blob/main/vercel/package.json#L11
😢