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

ci: release without committing to main branch #1434

Merged
merged 4 commits into from
Feb 18, 2025

Conversation

calumcalder
Copy link
Collaborator

Committing to the master branch isn't allowed from github actions because of our branch protection rules. There's no easy way to allow github actions to bypass this.

As a workaround, skip all the parts of the release that needed to commit to the repo. This means moving the version config to an environment variable, which shouldn't be an issue, and using git tags as the source of truth.

@calumcalder calumcalder requested review from jzacsh and lisad February 14, 2025 15:14
Committing to the master branch isn't allowed from github actions
because of our branch protection rules. There's no easy way to allow
github actions to bypass this.

As a workaround, skip all the parts of the release that needed to commit
to the repo. This means moving the version config to an environment
variable, which shouldn't be an issue.
Copy link
Collaborator

@jzacsh jzacsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for figuring this all out! Feel free to ack/ignore all these since they're all optional!

Co-authored-by: Jonathan Zacsh <[email protected]>
@calumcalder
Copy link
Collaborator Author

Thanks for the suggestions! Applied them all

jzacsh
jzacsh previously approved these changes Feb 18, 2025
@calumcalder calumcalder merged commit 32eb7cc into dtinit:master Feb 18, 2025
6 checks passed
@jzacsh
Copy link
Collaborator

jzacsh commented Feb 19, 2025

Hey @calumcalder if I understand this latest tag correctly, then it:

  1. was autogenerated from our new code here
  2. bumped us v1.0.4 --> v1.1.0

Is that kind of bump what we want? Or would we expect just a patch bump for a commit like this? (ie: do we want it to have done v1.0.4 --> v.1.0.5?). If we just want patch, then looks like we just need to tweak our bump CLI call to pass --increment-mode PATCH flag:

-          NEW_VERSION=$(cz bump --get-next) || exit 1
+          NEW_VERSION=$(cz bump --get-next --increment-mode PATCH) || exit 1

@calumcalder
Copy link
Collaborator Author

calumcalder commented Feb 20, 2025

@jzacsh The bump from 1.0.4 to 1.1.0 was intentional - it calculates it from the difference between HEAD and the previous tag, and there have been a lot of commits between v1.0.4 and now, including some feat: commits which should bump the minor version - v1.0.4...v1.1.0
This release was a bit of an outlier since future releases should only contain 1 PR each

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

Successfully merging this pull request may close these issues.

2 participants