You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Craft releases themselves are published with this repository workflow. Whenever there's a broken Craft release, all releases, including Craft's, are affected and require manual operator intervention as in #577, where we had to temporarily hard-pin the image version to a known state to unblock releases.
We could make an operator's life easier, and their job safer, by allowing the version to be chosen without requiring temporary patches to the publish workflow.
How exactly that's done is up for debate. Some options:
Dropdown in the release issue to choose the version, pre-populated with the last few Craft versions
Use the minimum craft version as specified in the .craft.yml config of the target repo
Use some "known-to-be-stable" version and bump that periodically
All with pros and cons.
The text was updated successfully, but these errors were encountered:
You'd need to find a way to incorporate and relay that information through the issue format. I'd say it is definitely not worth the hassle and complexity as you can easily pin/fix the craft version.
A more important issue is publish always using the latest master build of craft whereas action-prepare-release using the latest released version.
The publish process always use the latest Craft Docker image (with the latest published version of the
craft
binary):publish/.github/workflows/publish.yml
Lines 49 to 50 in e991410
Craft releases themselves are published with this repository workflow. Whenever there's a broken Craft release, all releases, including Craft's, are affected and require manual operator intervention as in #577, where we had to temporarily hard-pin the image version to a known state to unblock releases.
We could make an operator's life easier, and their job safer, by allowing the version to be chosen without requiring temporary patches to the publish workflow.
How exactly that's done is up for debate. Some options:
.craft.yml
config of the target repoAll with pros and cons.
The text was updated successfully, but these errors were encountered: