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

Sync proto #1849

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/main.yml
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ jobs:
- uses: arduino/setup-protoc@c65c819552d16ad3c9b72d9dfd5ba5237b9c906b # v3.0.0
name: Install protobuf
with:
version: '28.0'
version: '28.3'
repo-token: ${{ secrets.GITHUB_TOKEN }}

- name: Build
Expand Down
2 changes: 1 addition & 1 deletion hack/tools/go.mod
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
module github.com/sigstore/fulcio/hack/tools

go 1.22.5
go 1.23
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we keep this synced with go.mod in project root dir?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no strong options as this will get any patch release of go

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there general guidance on go 1.x.y vs go 1.x? We used to only do the latter, and then at some point, Go forced us to specify each patch release.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that will say the minimum go version, if we pin to a patch for example go 1.22.8 it will not build with go1.22.7, but if we say go 1.22 it will work for all

but if one of the deps have a patch pinned i think that will come the toolchain that will force to use a pinned go version

that is my understanding


require (
github.com/googleapis/api-linter v1.67.3
Expand Down
Loading