IS_DEVELOPMENT_BUILD to false
This is more streamlined than the previous approach, and works better
for a world where 1 person isn't doing all the work.
Now, the flow is simpler:
- Do changes (e.g. protocol update), changelog & set IS_DEVELOPMENT_BUILD to false all in a single PR, which can be squash-merged if desired
- Once the PR is merged, a draft release will be prepared
- RestrictedActions will automatically set IS_DEVELOPMENT_BUILD back to
true and bump the version
- Tag will be created when the release is published
Previously, multiple PRs might be needed, and the PR containing the
release changelog couldn't be squash-merged. Manual intervention was
also required to create a tag and prepare a release.
This PR also includes new CI checks to check for basic errors like
forgotten changelog files to ensure changelog links work correctly.
Note: Only PRs from PMMP Team members with **write** access to the
repository can trigger release generation. Random people cannot trigger
release generation by sending PRs.
this popped up due to new changes in 1.20.40. Really we need to improve the way the filters are calculated, but this workaround solves the issue for now.
This field was added to the action in 1.21.20. Previously, the client would behave as if clicking the crafting result slot many times. Now it behaves more like recipe book shift-clicking.
Branch protection rules currently require 2 approving reviews to merge a PR. What we really want is for 2 team members to be aware of every change. If a team member makes a PR, only one other approval should be needed.
Since GitHub doesn't currently allow us to set different review thresholds for different users/teams, sending an automatic approval via GitHub Actions is the next best thing. This should reduce friction of team development work.
