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

Have generic updater support numbers without breaks #1344

Open
jeremytchang opened this issue Mar 22, 2022 · 2 comments
Open

Have generic updater support numbers without breaks #1344

jeremytchang opened this issue Mar 22, 2022 · 2 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@jeremytchang
Copy link

jeremytchang commented Mar 22, 2022

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.

// x-release-please-start-major
module github.com/jeremytchang/test-release-please-go/go/v4

// x-release-please-end

go 1.14

Currently, the generic updater can only update the major version if it is a number by itself. The regex: /\b\d+\b/

const SINGLE_VERSION_REGEX = /\b\d+\b/;

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.

@jeremytchang jeremytchang added priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Mar 22, 2022
jeremytchang added a commit to looker-open-source/sdk-codegen that referenced this issue Mar 23, 2022
…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
jeremytchang added a commit to looker-open-source/sdk-codegen that referenced this issue Mar 23, 2022
…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
@ammmze
Copy link

ammmze commented Oct 27, 2023

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 -->

@t3mi
Copy link

t3mi commented Nov 9, 2023

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@&#x0076;1 <!-- x-release-please-major -->
  with:
    project-id: 100
</pre>
  • using html tags for syntax highlighting along with the html comment wont produce the comment in the rendered output
  • switch letter v to the unicode value of &#x0076; to please the current regex pattern for single version part update allows major version upgrades for example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

3 participants