-
Notifications
You must be signed in to change notification settings - Fork 358
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
Have generic updater support numbers without breaks #1344
Comments
…lish CI - Updated release-please to latest v3 from v2 that contains the needed functionality for releasing Go SDK. The breaking changes should not affect us: https://github.com/google-github-actions/release-please-action/releases/tag/v3.0.0 - Setup release-please config to release Go SDK at v0 only.-- To release Go SDK at v1 and above requires automated editing of the module name in go.mod during SDK generation or when release-please creates a release PR. Release-please gi thub issue: googleapis/release-please#1344 -- The repo tag must be in the exact format of "go/vX.X.X". So package-name and tag-separator in release-please-config.json are set accordingly - Setup release-please-manifest to point go sdk to 0.0.1. 0.0.0 is automatically bumped to 1.0.0 ignoring the "pre-major" release-please configs. - Setup a go publish github action that publishes go module to go proxy based off the new tag - Updated go.mod and go.sum with go mod tidy which cleans up dependencies
…blish CI (#1030) - Updated release-please to latest v3 from v2 that contains the needed functionality for releasing Go SDK. The breaking changes should not affect us: https://github.com/google-github-actions/release-please-action/releases/tag/v3.0.0 - Setup release-please config to release Go SDK at v0 only.-- To release Go SDK at v1 and above requires automated editing of the module name in go.mod during SDK generation or when release-please creates a release PR. Release-please gi thub issue: googleapis/release-please#1344 -- The repo tag must be in the exact format of "go/vX.X.X". So package-name and tag-separator in release-please-config.json are set accordingly - Setup release-please-manifest to point go sdk to 0.0.1. 0.0.0 is automatically bumped to 1.0.0 ignoring the "pre-major" release-please configs. - Setup a go publish github action that publishes go module to go proxy based off the new tag - Updated go.mod and go.sum with go mod tidy which cleans up dependencies
I would also like something like this but for a custom action for Github Actions. I'd like to use it to keep the code sample in the readme current with the major version. However, in my case, i'd like those markings to be outside the code block so they are hidden when viewing the readme, but if the pattern was just looking for a number, it would match other things easily that it shouldn't match. I think it would be neat if the markers/tags allowed for a custom pattern with a capture like the following: <!-- x-release-please-start-major pattern="v(\d+)" -->
```yaml
- uses: ammmze/example@v1
with:
project-id: 100
```
<!-- x-release-please-end --> |
I'd agree that regex should be changed for single digit as behavior for it doesn't match the one for the full version value @ammmze your case could already be covered with some hack assuming its only markdown in GitHub: <pre lang="yaml">
- uses: ammmze/example@v1 <!-- x-release-please-major -->
with:
project-id: 100
</pre>
|
I'm looking to support go major versioning where in a go.mod file last part of the module path must be the major version with
v
prefixed.Currently, the generic updater can only update the major version if it is a number by itself. The regex:
/\b\d+\b/
release-please/src/updaters/generic.ts
Line 21 in c97598c
What do you all think of simplifying it to just
/\d+/
example or/\bv?d+\b/
example or something along those lines.It would still support the current use case. Though it could break current implementations that have a line like
blah/12/blah 12
where both 12's will be replaced.The text was updated successfully, but these errors were encountered: