fix: fix the Go module path

[suzuki-shunsuke]

Summary

This pull request replaces "github.com/slsa-framework/slsa-github-generator with "github.com/slsa-framework/slsa-github-generator/v2.

git_replace () {
	git grep -l "$1" | xargs -n 1 gsed -i "s|$1|$2|g"
}

git_replace '"github.com/slsa-framework/slsa-github-generator' '"github.com/slsa-framework/slsa-github-generator/v2'

The latest version of slsa-github-generator is https://github.com/slsa-framework/slsa-github-generator/releases/tag/v2.1.0 , so we should update the Go module path to github.com/slsa-framework/slsa-github-generator/v2.

Otherwise, packages are unavailable.

v1.10.0 is available.

$ go install github.com/slsa-framework/slsa-github-generator/internal/builders/[email protected]

But v2.1.0 is unavailable.

$ go install github.com/slsa-framework/slsa-github-generator/internal/builders/[email protected] 
go: github.com/slsa-framework/slsa-github-generator/internal/builders/[email protected]: github.com/slsa-framework/[email protected]: invalid version: module contains a go.mod file, so module path must match major version ("github.com/slsa-framework/slsa-github-generator/v2")

$ go install github.com/slsa-framework/slsa-github-generator/v2/internal/builders/[email protected]
go: github.com/slsa-framework/slsa-github-generator/v2/internal/builders/[email protected]: github.com/slsa-framework/[email protected]: invalid version: module contains a go.mod file, so module path must match major version ("github.com/slsa-framework/slsa-github-generator/v2")

Testing Process

...

Checklist

• Review the contributing guidelines
• Add a reference to related issues in the PR description.
• Update documentation if applicable.
• Add unit tests if applicable.
• Add changes to the CHANGELOG if applicable.

[ramonpetgrave64]

Thanks for filing this.

My apologies. When I release v2.0.0 last year I was still very new to Go's package ecosystem. To fix this, I think we'll need to release a new tag, as well. And probably a new version of slsa-verifier.

Can you tell us about your your use case for using that internal executable directly?

It could take to go through the release process, but in the meantime, I think using the git commit digest could be okay. Let me know.

go install github.com/slsa-framework/slsa-github-generator/internal/builders/go@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a # v2.1.0

[suzuki-shunsuke]

To fix this, I think we'll need to release a new tag, as well. And probably a new version of slsa-verifier.

I think so too.

Can you tell us about your your use case for using that internal executable directly?

I don't use slsa-builder-go directly.
I'm the author of aqua, which is a CLI version manager.
aqua supports slsa-builder-go, but now aqua can't install slsa-builder-go v2 on other than linux/amd64 due to this issue.

https://github.com/aquaproj/aqua-registry/blob/7ead7543e4edb5e4c1963b886c42d9d9cd34a9d9/pkgs/slsa-framework/slsa-github-generator/slsa-builder-go/registry.yaml

I'm not sure who installs slsa-builder-go by aqua and how he/she uses it.

[ianlewis]

My apologies. When I release v2.0.0 last year I was still very new to Go's package ecosystem. To fix this, I think we'll need to release a new tag, as well. And probably a new version of slsa-verifier.

What do you think would need to be changed besides the import paths? I think it would require changes to folks importing the package downstream (including slsa-verifier) but would it need a new release?

BTW, there are a few other projects that import the packages directly. We should probably consider stopping support for importing them at some point since I can imagine a future where many packages aren't needed anymore and go away (note that internal/ packages carry no implicit assumptions of support however). We originally imagined these packages making up a utility library but that ambition quickly faded I think, especially after BYOB and transitioning to writing actions using TypeScript.