rlespinasse / release-that Goto Github PK

To ease integration in an existing repository or PR system

Sometimes we only want X.Y.Z and not vX.Y.Z

Currently, the action assumes you don't use package.json file and create a new one.

See https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#configuration

Using https://github.com/semantic-release/git, enable action configuration (with default values) to add modified files and folders before the release tag. Useful for javascript dist folder for example.

• add contributing page
• add code of conduct page (#6)
• add developer guide

The user can select the working directory to make the release.

New Inputs

• working-directory to work inside a specific folder using the relative path from GitHub workspace
  • <empty> by default
• git-tag-prefix: to specify the prefix to use as git tag with the version
  • v by default
  • <directory_name>@v by default if the input working-directory is used

Deprecated Inputs

• without-prefix: use git-tag-prefix instead
  • true => git-tag-prefix: ""
  • false => git-tag-prefix: v

Under the wood

• use cycjimmy/semantic-release-action input : working_directory
• use git-tag-prefix on major tag management (except for empty string, use v : same behavior as before)

Read https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/ for more information

see https://github.com/rhysd/actionlint

Instead of doing this manually, we can use a GitHub Action workflow to periodically watch for newly released versions.

Check this project for the right awesome-actions section based on Marketplace categories

https://github.com/sdras/awesome-actions

It would be interesting to support also mono repo project.

In order to improve the governance and the future of this action, I created a GitHub organization called Actions-Able which is composed of other action maintainers and co-maintainers I work with.

This issue concerns preparing the migration to this new ownership without breaking the current use of rlespinasse/release-that@... in our user workflows.

Using this action in a GitHub Action workflow

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

A usecase is to follow a GitHub Action recommendation about tagging release on an action.

• a new 1.0.0 tag will also produce a v1 tag
• a new 1.1.0 tag will overwrite the v1 tag
• a new 2.0.0 tag will also produce a v2 tag

By example, use:

          extra_plugins: |
          @semantic-release/commit-analyzer
          @semantic-release/git
          @semantic-release/github

Instead of

extra_plugins: |
          @semantic-release/commit-analyzer
          @semantic-release/release-notes-generator
          @semantic-release/git
          @semantic-release/github

Limitations are explain on https://docs.github.com/en/actions/security-guides/automatic-token-authentication

• Explain the purpose of this action
• Add badges
• Add usage examples

https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

Useful to build PR comment with resulting dry-run of this action