Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a generic script-based release strategy #1139

Closed
raphink opened this issue Dec 8, 2021 · 3 comments · Fixed by #1157
Closed

Add a generic script-based release strategy #1139

raphink opened this issue Dec 8, 2021 · 3 comments · Fixed by #1157
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@raphink
Copy link

raphink commented Dec 8, 2021

It would be useful to be able to launch a custom script from the GitHub repo to update specific files without having to create a new type of release strategy in release-please.

Something like:

 jobs:
   release-please:
     runs-on: ubuntu-latest
     steps:
       - uses: GoogleCloudPlatform/release-please-action@v2
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           release-type: exec
           command: update-my-files.sh

The script would then receive the version number as parameter and be able to perform actions on the repository before release-please commits the files to the branch.

@chingor13 chingor13 added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label Dec 8, 2021
@chingor13
Copy link
Contributor

FYI, this might be difficult to accomplish. We generate the file changes in code and do not have a clone of the repository while creating the release pull request.

@raphink
Copy link
Author

raphink commented Dec 10, 2021

Thanks for your feedback @chingor13. I have 3 files I need to update with the version number:

  • a Terraform variable file with a target_revision variable which should default to the version
  • a config.toml file for gohugo to make the website point to the right version of the docs
  • a antora.yml file to generate the docs for the right version

Is there already a way to achieve this with release-please?

@chingor13
Copy link
Contributor

I don't see a great way right now, but 2 options moving forward.

  1. Implement the generic update class like develop more generic "update" class for long-tail of version replacements #305
  2. Add a feature to let you arbitrarily add extra updaters (we have a TOML updater, and could build updaters for the other 2 file types) via path + updater. This one could be challenging, because some updaters have extra customizable arguments used.

Another option could be to use a manifest (multi-component) configuration with a plugin like the one requested in #1075. This would only work if the 3 files you want to update are in different directories though and would not be as globally applicable as options 1 and 2.

chingor13 added a commit that referenced this issue Dec 29, 2021
This introduces a new `Generic` updater class that scans the file line by line for annotations.

You can annotate a line (inline) via:
* `x-release-please-version`
* `x-release-please-major`
* `x-release-please-minor`
* `x-release-please-patch`

For these annotations, we will try to replace the value on that line only.

You can annotate a block by starting with a line containing:
* `x-release-please-start-version`
* `x-release-please-start-major`
* `x-release-please-start-minor`
* `x-release-please-start-patch`

and close the block with a line containing `x-release-please-end`. Within the block, we will attempt to replace version values.

Additionally, all basic strategies now support the `extra-files` option which will apply this generic updater class.

Fixes #435
Fixes #305
Fixes #1139
Fixes #1174
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants