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

Use a set for the list to avoid duplicates #12

Merged
merged 1 commit into from
Nov 22, 2023
Merged

Conversation

jhrozek
Copy link
Contributor

@jhrozek jhrozek commented Nov 21, 2023

I was being silly and did just appended blindly to a single slice which resulted in duplicates. Using a set seems like the cleanest option. On the API boundary, a plain slice is returned (I don't like returning 3rd party types from a public API..). There's also a new function to list all actions in a directory what I think the majority of users would like (except when parsing patches).

I was being silly and didn't just appended blindly to a single slice
which resulted in duplicates. Using a set seems like the cleanest
option. On the API boundary, a plain slice is returned (I don't like
returning 3rd party types from a public API..). There's also a new
function to list all actions in a directory what I think the majority of
users would like (except when parsing patches).
@JAORMX
Copy link
Contributor

JAORMX commented Nov 21, 2023

Have you tested this? I'm impressed the set works with a structure since it's a non-hashable object in golang

@jhrozek
Copy link
Contributor Author

jhrozek commented Nov 21, 2023

Have you tested this?

Yes:

rg -NI uses\: .github/workflows/*  | sort | uniq
        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4
        uses: actions/download-artifact@9bc31d5ccc31df68ecc42ccf4149144866c47d8a # v3
        uses: actions/setup-go@93397bea11091df50f3d7e59dc26a7711a8bcfbe # v4
        uses: actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32 # v3
        uses: anchore/sbom-action/download-syft@78fc58e266e87a38d4194b2137a3d4e9bcaf7ca1 # v0.14.3
        uses: arduino/setup-task@e26d8975574116b0097a1161e0fe16ba75d84c1c # v1
        uses: golangci/golangci-lint-action@3a919529898de77ec3da873e3063ca4b10e7f5cc # v3
        uses: goreleaser/goreleaser-action@7ec5c2b0c6cdda6e8bbb49444bc797dd33d74dd8 # v5
        uses: sigstore/cosign-installer@1fc5bd396d372bee37d608f955b336615edf79c8 # v3.2.0
        uses: slsa-framework/slsa-verifier/actions/installer@7e1e47d7d793930ab0082c15c2b971fdb53a3c95 # v2.4.1
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]

vs:

./bin/frizbee ghactions list | jq '.[] | "\(.Owner)/\(.Repo)@\(.Ref)"' | sort | uniq
"actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11"
"actions/download-artifact@9bc31d5ccc31df68ecc42ccf4149144866c47d8a"
"actions/setup-go@93397bea11091df50f3d7e59dc26a7711a8bcfbe"
"actions/upload-artifact@a8a3f3ad30e3422c9c7b888a15615d19a852ae32"
"anchore/sbom-action@78fc58e266e87a38d4194b2137a3d4e9bcaf7ca1"
"arduino/setup-task@e26d8975574116b0097a1161e0fe16ba75d84c1c"
"golangci/golangci-lint-action@3a919529898de77ec3da873e3063ca4b10e7f5cc"
"goreleaser/goreleaser-action@7ec5c2b0c6cdda6e8bbb49444bc797dd33d74dd8"
"sigstore/cosign-installer@1fc5bd396d372bee37d608f955b336615edf79c8"
"slsa-framework/[email protected]"
"slsa-framework/slsa-verifier@7e1e47d7d793930ab0082c15c2b971fdb53a3c95"

they seem to be the same..

I'm impressed the set works with a structure since it's a non-hashable object in golang

The type only needs to be comparable according to the docs
btw the library is apparently used by Hashi, 1Password and others

@jhrozek
Copy link
Contributor Author

jhrozek commented Nov 21, 2023

Hmm, not related to this patch per se I guess, but I think we have a bug somewhere. One of the uses says:

slsa-framework/slsa-verifier/actions/installer@7e1e47d7d793930ab0082c15c2b971fdb53a3c95

but the corresponding list says:

"slsa-framework/slsa-verifier@7e1e47d7d793930ab0082c15c2b971fdb53a3c95"

@JAORMX
Copy link
Contributor

JAORMX commented Nov 21, 2023

Hmm, not related to this patch per se I guess, but I think we have a bug somewhere. One of the uses says:

slsa-framework/slsa-verifier/actions/installer@7e1e47d7d793930ab0082c15c2b971fdb53a3c95

but the corresponding list says:

"slsa-framework/slsa-verifier@7e1e47d7d793930ab0082c15c2b971fdb53a3c95"

Remind me tomorrow, let's figure it out

@jhrozek jhrozek merged commit c76466a into stacklok:main Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants