we're having problems with the restricted action getting disabled due to repo inactivity,
so it's best we trigger it from here, since this repo's activity is what it's
interested in anyway.
these are noisy and cause conflicts. Since they also usually cause new errors to be reported, we often can't directly update it anyway. Better to test & update this locally.
having two different workflows able to trigger releases is a pain for build number continuity.
perhaps longer term we should source the build number a different way, but these workflows needed restructuring anyway.
this doesn't work for PRs from forks, since fork PRs don't have access to repo secrets.
we'll need some more advanced mechanism to avoid redundant reviews, but that's a job for another time.
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.
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.
