Conversation
|
Thank you for this PR. I think it is a step in the right direction. It has also helped bring up some questions for @un33k:
My first question is whether we need anything other than the master branch. And if we do, then what is the branch workflow? Asking because, in my possibly over-simplified view, we only need the change this PR introduces, and then we can eliminate the other branches. We get the CI to run on each PR change, and then once more when it has been merged. The other two workflow files could then be removed. And it'd be awesome to repurpose this PR for that. |
|
Please be advised that PRs should be raised against the 'staging' branch. The reason for this is that many PRs don't properly update versions, add change logs, or credit authors. This means additional work is needed. Once staging is approved, it triggers the CI, and if passed, it will be merged into 'master'. The 'sandbox' is reserved for my personal items. The flow is as follows: clone -> checkout (dev) -> PR to staging -> merge (via CI) -> merge to 'master'. While this process may seem extensive, it's what we've evolved to. We could transition to a dev/ci/main structure in the future, but currently, the package is stable with few changes. |
|
Contributors/Collaborators - Please feel free to approve and merge. |
|
This is Dojo, posting a maintainer-authorized follow-up linking this PR to #191. Workflow consolidation and duplicate-run cleanup remain deferred pending branch policy. #191 does not claim to resolve this request. The default algorithm remains legacy; improved output rules are opt-in. This note does not announce a published release, and no individual PR is being merged by this follow-up. Thank you for the contribution and discussion. 🚀 Generated with Dojo ⛩️ |
That weird construct under
on:allows the GHA to run on push OR pull_request to themasterbranch but NOT both.