Skip to content

NASA-IMPACT/csda-version

Use this GitHub action with your project
Add this Action to an existing workflow or create a new one
View on Marketplace

Repository files navigation

csda-version

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.

CSDA version

A CSDA version is formatted like vYY.PI.SP-X, where:

  • YY is the last two digits of the year,
  • PI is the "program increment", which is like a normal calendar quarter except that PI 1 starts Oct 1
  • SP is the sprint number
  • X is 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.

Commit Messages

Release Please only recognizes feat and fix commit prefixes when generating automated releases.

Examples

git commit -m "feat: add user authentication"
git commit -m "fix: merge conflicts"

Breaking Changes

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.

Common Prefixes

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.

About

Custom release-please configuration for CSDA

Resources

License

Stars

Watchers

Forks

Contributors

Languages