ci: introduce releases #48
Conversation
| [ | ||
| "@semantic-release/commit-analyzer", | ||
| { | ||
| "releaseRules": [ |
There was a problem hiding this comment.
Shall we consider a breaking change as Major release, while Minor release for feat and Patch release for bugfixes ?
As I can see that's the default for commit-analyzer and some other projects I have checked.
https://github.com/semantic-release/commit-analyzer/blob/master/lib/default-release-rules.js
There was a problem hiding this comment.
yes, but I'm following what we have for terraform modules. Until the project is mature enough let's not produce to many majors or minors. We might end up with a really high major release w/o actually introducing any features, but just by fixing our own bugs.
I would stick with the current rules until we agree that we can hit ver 1.0.0, then let's go for the default rules.
| - name: Install Python | ||
| uses: actions/setup-python@v4 | ||
| with: | ||
| python-version: 3.11 |
There was a problem hiding this comment.
Shall we run on python 3.8 (as the oldest version we support) or it doesn't matter here?
There was a problem hiding this comment.
that's the env to run the tools, not the env to run tests or the code itself. When we go for the actual pytests we will do a matrix run, against each supported Python version
| id: rc | ||
| uses: cycjimmy/semantic-release-action@v3 | ||
| with: | ||
| dry_run: true |
There was a problem hiding this comment.
Shall we explicitly set the ci: true as well? It says the following in the semantic release action github page.
ci can be used, e.g in combination with dry_run when generating the next release version in pull requests, where semantic_release would normally block the execution.
There was a problem hiding this comment.
nope, as this action discovers if it runs inside CI. For commonly used CIs this works pretty well (we use it for Terraform in the same way). You might want to use ci: true if you run it in some exotic environment.
Github sets an env variable, GITHUB_ACTION or something similar, that is being discovered by semantic release action to check if this is a CI env.
| jobs: | ||
| lint_pr_title: | ||
| name: Lint PR | ||
| uses: PaloAltoNetworks/terraform-modules-vmseries-ci-workflows/.github/workflows/lint_pr_title.yml@plan-apply |
There was a problem hiding this comment.
I think it would be clear/better to include the step directly here instead of referencing ?
There was a problem hiding this comment.
nope, as this is our common CI repo. We do not want to copy over the code. The whole idea is to have it centralised.
Description
A simple CI to do automatic releases and PR tests.
Motivation and Context
We need something automatic that will:
How Has This Been Tested?
Tested on a copy of this repo
Screenshots (if appropriate)
Types of changes
chore, ci
Checklist