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

govulncheck: Use latest go #384736

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jimmidyson
Copy link

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@06kellyjac
Copy link
Member

@jimmidyson is there a specific reason this is necessary? If I had to guess I'd say maybe it fails to analyze newer copies of go than the copy it's built with?
If that's the case we might want to add a note to the main go packages to bump this to whatever latest buildGoModule when go itself is updated

Also @SuperSandro2000 do we still prefer changing go version in all-packages.nix?

@jimmidyson
Copy link
Author

@jimmidyson is there a specific reason this is necessary? If I had to guess I'd say maybe it fails to analyze newer copies of go than the copy it's built with? If that's the case we might want to add a note to the main go packages to bump this to whatever latest buildGoModule when go itself is updated

Correct. It has to be built with a language version (minor version) of go equal to or later than the language version of the project it is analysing.

Also @SuperSandro2000 do we still prefer changing go version in all-packages.nix?

I followed the approach #382567 which @SuperSandro2000 submitted for golangci-lint. Hope that's ok.

@06kellyjac
Copy link
Member

In the past we've done it in all-packages but now that we're using pkgs/by-name I guess the preference is to do so inside the package.nix definition.

I think for this specific case it'd be best to add it to all-packages right next to the other go stuff (search for DEVELOPMENT / GO) that'd be easier to keep updated alongside go overall in nixpkgs.

maybe with a comment above it like # update to latest buildGoModule or # update in tandem with go (where possible) to maintain scanning compatibility ?

@SuperSandro2000
Copy link
Member

cross-ref #384229

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants