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

Setup action v0.2.1 failing on GitHub Enterprise Server #10

Closed
palloberg opened this issue Oct 16, 2024 · 6 comments · Fixed by #12
Closed

Setup action v0.2.1 failing on GitHub Enterprise Server #10

palloberg opened this issue Oct 16, 2024 · 6 comments · Fixed by #12
Assignees

Comments

@palloberg
Copy link

palloberg commented Oct 16, 2024

Hi.

When running on a self hosted GitHub Enterprise Server (GHES) the new version of setup-trivy is failing because it's using the checkout action without allowing the token and github-server-url to be overridden. In that case it tries to check out contrib/install.sh from aquasecurity/trivy on the local GHES instead of from https://github.com/aquasecurity/trivy.

Updating setup-trivy (and the trivy-action) with optional parameters for token and github-server-url and passing those to actions/checkout would probably make it compatible with GHES as well (although more config would be needed for users of the action on GHES).

image

@palloberg
Copy link
Author

Alternatively fetching the install.sh from https://raw.githubusercontent.com/aquasecurity/trivy/refs/heads/main/contrib/install.sh (or https://raw.githubusercontent.com/aquasecurity/trivy/refs/tags/SOMETAG/contrib/install.sh when another version than latest is requested) would bypass the whole authentication problem.

@m-breitbach
Copy link

m-breitbach commented Oct 16, 2024

Since recently, we have a similar problem on our GHES, also with the checkout step. In our case, the default branch cannot be determined by the checkout action, I believe because it is operating on github.com URLs.

@DmitriyLewen
Copy link
Contributor

Hello @palloberg @m-breitbach
Unfortunately, i don't have GHES runner and my self-hosted runner works correctly - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380381891

But i investigated this issue and looks like we always need to use http://github.com as github-server-url.
It works for me - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380839756/job/31660961664

Can you test these changes with GHES?
use commit from my fork (uses: DmitriyLewen/setup-trivy@108c12b3f1803ed4e0e9780fb857f6b00946cb56)

with optional parameters for token and github-server-url

trivy is a public repository. I hope rewriting token doesn't break action/checkout.

We probably don't need to add input for github-server-url, since in all cases action/checkout in setup-trivy should connect to the github.com server.
we will explicitly indicate this server and that will be enough

@palloberg
Copy link
Author

Hi @DmitriyLewen. Thanks for looking into this.

Hello @palloberg @m-breitbach Unfortunately, i don't have GHES runner and my self-hosted runner works correctly - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380381891

But i investigated this issue and looks like we always need to use http://github.com as github-server-url. It works for me - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380839756/job/31660961664

Can you test these changes with GHES? use commit from my fork (uses: DmitriyLewen/setup-trivy@108c12b3f1803ed4e0e9780fb857f6b00946cb56)

For GHES the checkout action is using the hostname of the local GHE server ("the same instance that the workflow is running from unless specified" is what the docs there say), so doing as you did in your fork and hard-coding it to https://github.com should do the trick.

with optional parameters for token and github-server-url

trivy is a public repository. I hope rewriting token doesn't break action/checkout.

When running on GHES the token created for the workflow is not valid on GitHub.com. So a valid GitHub.com token must be passed to the workflow in that case. If that is not set the default ${{ github.token }} should be used instead.

As long as that parameter is optional and defaults to ${{ github.token }} it will not break anything when running on GitHub.com, but will allow GHES users to provide a token valid on GitHub.com.

Typically adding this to action.yml will do the trick:

inputs:
  githubcom-token:
    description: >
     Access token for reading from GitHub.com when the action is running on GitHub Enterprise Server (GHES).
     https://github.com/actions/create-github-app-token can be used to obtain such a token. The token only need to 
     be scoped with read access to public repositories.
    default: ${{ github.token }}

Then pass that input to actions/checkout.

The aquasecurity/trivy-action would also need to be updated with the same input and pass that to setup-trivy.

A user of GHES can then utilize https://github.com/actions/create-github-app-token to create a token for GitHub.com and pass that to aquasecurity/trivy-action and it will flow down to the checkout action.

We probably don't need to add input for github-server-url, since in all cases action/checkout in setup-trivy should connect to the github.com server. we will explicitly indicate this server and that will be enough

That's true. Using https://github.com should be sufficient as that's where the trivy org is located.

@DmitriyLewen
Copy link
Contributor

@palloberg thanks for this information!
Can you test setup-trivy from #12?

@palloberg
Copy link
Author

Tested the trivy-action@master now with the new token-setup-trivy parameter it it works like a charm. Thank you!

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 a pull request may close this issue.

3 participants