-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix: update CI/CD process to use composite actions and auto-release workflow #361
fix: update CI/CD process to use composite actions and auto-release workflow #361
Conversation
@@ -1,12 +1,3 @@ | |||
# Change Log |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are removed since they will be managed by the semantic-release
plugin going forward. They will get added back in when the first release kicks off, just like it did here following this same process https://github.com/clowdhaus/terraform-aws-rds/blob/master/CHANGELOG.md#changelog
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few clarifications and questions mostly to become familiar with Semantic Release workflow.
.github/workflows/release.yml
Outdated
- master | ||
paths: | ||
- '*.tf' | ||
- 'modules/**/*.tf' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few questions:
- Does it mean that any change in these masks will trigger a release?
- Can
modules/**/*.tf
be generalize to be**/*.tf
to include changes inexamples/*
, too? Is it right, that this GH Action will decide on the scope based on the commit message type (Found answer on https://github.com/semantic-release/commit-analyzerfeat
=> major,fix:
=> minor,chore
=> patch). If so, do you know where the mapping is described? I can't find it on the GH Action homepage.- Is there any stop word to have in git commit message which will not trigger the release even if valid paths were changed? (e.g.
[ci skip]
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Correct - any PRs that match these path patterns will trigger a release and we can tailor the paths/pattern to whatever we choose
- Yes - I believe the pattern
**/*.tf
means any*.tf
file anywhere in the repo. However, if someone makes only a change to an example, I don't think that would be something "release worthy" since there are no source changes - 👍🏽
- Yes - there are a few patterns which do not trigger releases. I generally use commit messages like
chore: <something>
and this pattern does not trigger a release (skips it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If anyone changes tf files in examples and the git commit message starts with
fix:
, we should still release a patch version. To prevent this we can set the message to start withchore:
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated in 588f70e and added '**/*.py'
since that will come up in a few repos and this keeps the file uniform across the repos
also, I tried to update to pre-commit 1.54 but it seems to be broken on terraform-docs now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the report on broken terraform_docs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Please use v1.55.0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, updated to v1.55.0 🎉
.github/workflows/release.yml
Outdated
@semantic-release/changelog@6.0.0 | ||
@semantic-release/git@10.0.0 | ||
env: | ||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another "strange questions" from me :)
- Will this token be available for others to read? (eg. by adding another GH action YAML config and outputting
${{ secrets.GITHUB_TOKEN }}
there?) - What is the minimum scope of the token should we have? Reading this IMPORTANT note and I am not sure I understand if
Personal Access Token
should be used (we havemaster
as a protected branch).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This token is already there by default https://docs.github.com/en/actions/security-guides/automatic-token-authentication
- Let me get back to you on that, I'll have to create a token and do a bunch of test runs to see what permissions are required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok so it looks like we only need a token with public_repo
scope for this to work
I would store this as an org secret under the name SEMANTIC_RELEASE_TOKEN
. You can elect to select repos one by one as we add the workflow or allow all repos - up to you (will come up when you create the org secret as an option)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with: | ||
extra_plugins: | | ||
@semantic-release/changelog@6.0.0 | ||
@semantic-release/git@10.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
persist-credentials: false
should be used somewhere in the config, too, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use a personal access token then yes, we don't want to persist creds because they will conflict with the default token
Co-authored-by: Anton Babenko <anton@antonbabenko.com>
Sorry for the delay with this final review/check. I try to make it happen this week. |
No worries at all! I think I've got a solution for PR updates, stay tuned |
Ok, I have added PAT token with the correct name. Let me merge this one and see how it works before copying it to any other repositories. |
## [3.4.1](v3.4.0...v3.4.1) (2021-11-07) ### Bug Fixes * update CI/CD process to use composite actions and auto-release workflow ([#361](#361)) ([123ea2a](123ea2a))
🎉 This PR is included in version 3.4.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Looks good! Let me know if/when you have some news regarding pre-commit auto-fixes on behalf of users. |
I think I have the solution - started working on it and need to finish it up, maybe this week or next |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Description
terraform_docs
hook which avoids pinning to exact version due to conflict of .terraform.lock.hcl file (Ignore extracting versions from terraform.lock.hcl terraform-docs/terraform-docs#527)release.yml
workflow. this workflow will automatically:chglog
configs and MakefileThis takes what was completed for the Aurora module, and adds in one additional piece now which is the release workflow. I will open a PR on that module to add in these additional changes as well once we've proven they work as intended in this org
master
as a protected branch. If so, then we'll have to generate a GitHub PAT to use in the workflow in place of${{ secrets.GITHUB_TOKEN }}
. The default token provided by GitHub should work as intended if the branches are not protectedMotivation and Context
Breaking Changes
How Has This Been Tested?