chore: auto-release only when SwiftPM dependencies are updated#911
chore: auto-release only when SwiftPM dependencies are updated#911
Conversation
Enhance commit parsing and dependency management: - Add commit parsers to cliff.toml for better changelog categorization - Configure semantic commit scopes for dependencies and Swift Package Manager
There was a problem hiding this comment.
Pull Request Overview
This PR aims to ensure that new releases are only triggered when SwiftPM dependencies are updated, avoiding unnecessary releases due to changes in other dependencies.
- Adds a new commit_parsers section to classify commit messages based on type.
- Configures skip rules to exclude commits related to non-SwiftPM dependency updates and other chore tasks.
| { message = "^chore\\(pr\\)", skip = true }, | ||
| { message = "^chore\\(pull\\)", skip = true }, | ||
| { message = "^chore\\(release\\): prepare for", skip = true }, | ||
| { message = "^chore|^ci", group = "Miscellaneous Tasks" }, |
There was a problem hiding this comment.
The regex '^chore|^ci' may not function as intended. Consider grouping the alternatives as '^(chore|ci)' to ensure both options are anchored correctly.
| { message = "^chore|^ci", group = "Miscellaneous Tasks" }, | |
| { message = "^(chore|ci)", group = "Miscellaneous Tasks" }, |
fortmarek
left a comment
There was a problem hiding this comment.
would love to see added across our repositories. Long-term, we might want to see if we can share bits of cliff.toml, but it might be an overkill given we don't change it that often.
Yeah... with things like this, I don't know what's best, if having a centralized configuration that we can reuse or live with a bit of inconsistency which we fix over time? I check git-cliff to see if they support reading the configuration from another repository, and that's not supported. |
I noticed we were creating new releases when dependencies other than SwiftPM's got updated (e.g. Mise dependencies). We should not do this because an update of a Mise dependency has no relation with the XcodeProj package itself.
I'm mimicking the model that we adopted in Command where we configure Renovabebot differently to label PRs based on the package manager, and use the convention in the Git configuration to exclude some commits from the detection logic.