Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show Redwood Canary Version being deployed in README #103

Open
thedavidprice opened this issue Mar 22, 2022 · 2 comments
Open

Show Redwood Canary Version being deployed in README #103

thedavidprice opened this issue Mar 22, 2022 · 2 comments

Comments

@thedavidprice
Copy link
Contributor

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:

"@redwoodjs/core": "0.49.2-canary.151"

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

😢

@jeliasson
Copy link
Contributor

@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

@jeliasson
Copy link
Contributor

If you are not busy next week David, let's have a chat on this and docker images and how to move forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants