A Github action to calculate the next CSDA version for the checked-out repository.
To use with release-please:
steps:
- name: CSDA Version
id: csda-version
uses: NASA-IMPACT/csda-version@<hash-version> # hash-version is recommended for extra security
- uses: googleapis/release-please-action@<hash-version> # hash-version is recommended for extra security
with:
token: ${{ secrets.GITHUB_TOKEN }}
release-type: simple
release-as: ${{ steps.csda-version.outputs.version }}
config-file: ${{ steps.csda-version.outputs.release-please-config }}Important
You must use release-type in your Github Action YAML, you cannot use Manifest Driven releasing.
This is because release-as is ignored for manifest-driven releases.
To see this in action, check out https://github.com/NASA-IMPACT/csdap-frontend/blob/main/.github/workflows/release-please.yml.
A CSDA version is formatted like vYY.PI.SP-X, where:
YYis the last two digits of the year,PIis the "program increment", which is like a normal calendar quarter except that PI1starts Oct 1SPis the sprint numberXis the release number in this sprint
Note
While the CSDA version can be updated manually (see example commit), there is a Github cron job that runs weekly to handle routine updates.
Release Please only recognizes feat and fix commit prefixes when generating automated releases.
git commit -m "feat: add user authentication"
git commit -m "fix: merge conflicts"Appending an exclamation mark (!) to the prefix will add a BREAKING CHANGES header to the changelog. Use this sparingly and only for changes that introduce backward incompatibility.
For other standard commit types (such as refactor, chore, docs, or revert) pass them as a scope to feat or fix. If you need to trigger a release use:
git commit -m "fix(chore): update dependencies"
git commit -m "feat(docs): add new documentation"
git commit -m "feat(chore)!: breaking change in dependencies"Note: Commits without feat or fix prefixes will not trigger a new release, but they will still appear in the changelog.