-
Notifications
You must be signed in to change notification settings - Fork 24
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
feat: add go_version_file support #155
Conversation
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fixes from lint issues in README.md. Fixes bufbuild#155
046bc6b
to
ad16c02
Compare
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fixes from lint issues in README.md. Fixes bufbuild#155
ad16c02
to
83406df
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. A few notes:
- We can't promise we will merge this, but will consider it as a feature. We don't recommend adding github.com/bufbuild/buf as a way to install the CLI - this installation method is not officially supported.
- I've added a few comments to start with some questions.
- If we do accept this as a feature, revert all changes not related to the feature (ie changes to makefile, eslint, readme lint, etc), so that the PR only relates to the feature.
src/run.ts
Outdated
if (versionFilePath !== "") { | ||
if (version !== "") { | ||
core.warning( | ||
"Both version and go_version_file inputs are specified, go_version_file will be preferred" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would definitely prefer the version in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately that's not possible as version has a default.
src/run.ts
Outdated
const basename = path.basename(versionFilePath); | ||
if (basename === "go.mod" || basename === "go.work") { | ||
const match = contents.match( | ||
/^\s+github.com\/bufbuild\/buf v(\d+(?:\.\d+)*)/m |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work with non-released versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likely not I fix and will add a test for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I originally read this I was thinking that getBuf
dealt with hashed versions, but it seems to rely on tagged versions so if the user had pinned a specific unreleased hash this wouldn't work.
I don't think this is an issue it's unlikely to be something that's needed, thoughts?
@@ -22,6 +22,9 @@ inputs: | |||
description: The domain of the Buf Schema Registry to login to. | |||
required: false | |||
default: 'buf.build' | |||
go_version_file: | |||
description: The go.mod file to read the buf version from. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When would this ever be anything except go.mod? Why is this an option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on the structure of the repo it may not be in the root.
It also supports just a raw version in a file if the basename is not go.mod
, in the same way setup-go does.
@@ -22,6 +22,9 @@ inputs: | |||
description: The domain of the Buf Schema Registry to login to. | |||
required: false | |||
default: 'buf.build' | |||
go_version_file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about naming here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This matches the name that action/setup-go does with underscores instead of dashes to follow your existing naming convention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you prefer just version_file
that would work too?
@@ -30,8 +30,12 @@ format: node_modules | |||
lint: node_modules | |||
npm run lint | |||
|
|||
.PHONY: test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert changes to Makefile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure as if I did that so user wouldn't see test failures as added to support this feature?
Here's an example of the output from make test
or make
which now also adds test
to ensure the user fixes any issues they might introduce:
PASS __tests__/buf-setup.test.ts
buf-setup
go-version-file
✓ return version if go_version_file isn't set (122 ms)
✓ parses go.mod format if go_version_file contains go.mod basename (106 ms)
✓ returns contents if go_version_file is set to non go.mod filename (107 ms)
✓ reports failure if go_version_file doesn't exist (2 ms)
------------|---------|----------|---------|---------|-----------------------------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------|---------|----------|---------|---------|-----------------------------------------
All files | 48.96 | 26.82 | 62.5 | 48.96 |
buf.ts | 12.85 | 0 | 0 | 12.85 | 31-186
error.ts | 100 | 100 | 100 | 100 |
run.ts | 75 | 33.33 | 100 | 75 | 28,39,48,63,69,75,87-96,100-103,107-110
version.ts | 100 | 85.71 | 100 | 100 | 78
------------|---------|----------|---------|---------|-----------------------------------------
Test Suites: 1 passed, 1 total
Tests: 4 passed, 4 total
Snapshots: 0 total
Time: 1.693 s, estimated 3 s
Ran all test suites.
@@ -1,7 +1,7 @@ | |||
# `buf-setup-action` | |||
|
|||
This [Action] installs the [`buf`][buf-cli] CLI in your GitHub Actions pipelines so that it can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert readme lint edits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like these in a separate PR?
@@ -12,14 +12,20 @@ | |||
// See the License for the specific language governing permissions and | |||
// limitations under the License. | |||
|
|||
const ignoreFiles = [".eslintrc.js", "dist/**/*"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert all changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are needed otherwise linting will fail.
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fix lint issues in README.md. Fixes bufbuild#155
83406df
to
d1c8d39
Compare
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fix lint issues in README.md. Fixes bufbuild#155
d1c8d39
to
1ca48ab
Compare
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fix lint issues in README.md. Fixes bufbuild#155
1ca48ab
to
8ab8b05
Compare
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fix lint issues in README.md. Fixes bufbuild#155
8ab8b05
to
3863678
Compare
Thanks for the review, wasn't expecting that as I left it in draft to finish off this morning ;-) I've responded to all your notes with few questions and some clarification of the choices, looking forward to your feedback. |
Add support for determining the version of buf to use from go.mod including full test for the functionality. This allows go projects to have a single source for go module versions. Also: * Fix lint issues in README.md. Fixes bufbuild#155
3863678
to
31d86e4
Compare
@bufdev any feedback on this? |
Hey @stevenh - thanks for the PR, but we can't consider this at the moment. This isn't an officially supported installation path, and adding it as one isn't something we can budget for at this time unfortunately. We can revisit this in the future. |
Thanks for the feedback. It's obviously a shame as it means people either have to not use your action or when incrementing In case you haven't seen it versioning tools using |
We've seen that, but we don't think it's a good practice, and isn't one we support - we've seen numerous issues with users installing tools in this manner with dependencies overlapping with their own code's dependencies, causing builds of the buf binary to use untested dependencies. |
Hey @bufdev, Could you elaborate on this point:
The installation docs do call out installation from source using Agree with the take from @stevenh on this one. In a project where one is using the bufbuild GitHub actions alongside allowing folks to use Another pattern we've used in the past to help with this is using |
The new
This removes the edge case of go.mod having a non-release but version. Closing for now, please raise an issue in buf-action if this doesn't solve your usecase. |
Add support for determining the version of buf to use from go.mod including full test for the functionality.
This allows go projects to have a single source for go module versions.
Also:
Fixes #155