Add support for custom download URL

[mamercad]

This would help folks with GHES, etc

[eifinger]

Hi and thank you for your PR.

Can you please give a bit more information?

• How exactly does this help GHES users?
• What doesn't work currently?
• What is etc?

Thank you

[mamercad]

Hi and thank you for your PR.

Can you please give a bit more information?

• How exactly does this help GHES users?
• What doesn't work currently?
• What is etc?

Thank you

We run GHES and we would do something like this:

custom-download-url: "https://github.internal.tld/${OWNER}/${REPO}/releases/download/${version}/${artifact}${extension}"

I don't know TypeScript, so, guessing through things in this PR.

[eifinger]

I still don't understand why this change is needed. If you want to download from your own source, why do you need this action instead of "curl-ing" your private url and add the matchers?

[mamercad]

I still don't understand why this change is needed. If you want to download from your own source, why do you need this action instead of "curl-ing" your private url and add the matchers?

I don't know what you mean ... fine, closed.

[eifinger]

I am under the impression that you think I don't care and don't want to implement your changes.
On the contrary, I want to support you but I need to understand more in order to do that so that I can maintain this new feature once it is merged.

To give you some insight in what I am considering:

• Is this URL on the same GHES instance hosting the action?
• How do we test this given this we cannot host a GHES instance for testing?
• Will this work with the different versions of the Octokit client?
• Will this work with checksum validation?
• What are the possible error scenarios and how do we handle each?

[mamercad]

I am under the impression that you think I don't care and don't want to implement your changes. On the contrary, I want to support you but I need to understand more in order to do that so that I can maintain this new feature once it is merged.

I don't know much about this change that I'm trying to make here. What I'm getting from the security folks internally is something along the lines of "we don't want external dependencies like this" and what they're saying is "if custom-download-url could be our internal GHES that would help".

To give you some insight in what I am considering:

• Is this URL on the same GHES instance hosting the action?

That's the idea.

• How do we test this given this we cannot host a GHES instance for testing?

I don't know.

• Will this work with the different versions of the Octokit client?

I don't know what Octokit is.

• Will this work with checksum validation?

No idea.

• What are the possible error scenarios and how do we handle each?

No idea.

[eifinger]

Your security folks probably want to shutdown down internet access for the runner and look into https://docs.github.com/en/enterprise-server@3.15/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access#populating-the-tool-cache-for-a-self-hosted-runner

That being said I am currently verifying where the action downloads the executable when running in a GHES context in astral-sh/setup-uv#268 (comment).

When we learn more in this issue it might be that the change you propose here isn't even needed. I currently assume that it tries to hit a version of the astral-sh/ruff repository "mirrored" on the GHES instance.

[mamercad]

Your security folks probably want to shutdown down internet access for the runner and look into https://docs.github.com/en/enterprise-server@3.15/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access#populating-the-tool-cache-for-a-self-hosted-runner

We/they do this already.

That being said I am currently verifying where the action downloads the executable when running in a GHES context in astral-sh/setup-uv#268 (comment).

When we learn more in this issue it might be that the change you propose here isn't even needed. I currently assume that it tries to hit a version of the astral-sh/ruff repository "mirrored" on the GHES instance.

Yeah, I think that's the idea.

[eifinger]

For my understanding: It is easier for your security team to host ruff executables where they can be downloaded by this action rather than distributing them to the toolcaches on the hosted runners?

[mamercad]

For my understanding: It is easier for your security team to host ruff executables where they can be downloaded by this action rather than distributing them to the toolcaches on the hosted runners?

Yes, I believe that's what they'd prefer.

[mamercad]

For my understanding: It is easier for your security team to host ruff executables where they can be downloaded by this action rather than distributing them to the toolcaches on the hosted runners?

Yes, I believe that's what they'd prefer.

Also, I have a workaround (I'm currently just running ruff by way of pre-commit); and as such, I'm not sure I need this after all.

[eifinger]

For my understanding: It is easier for your security team to host ruff executables where they can be downloaded by this action rather than distributing them to the toolcaches on the hosted runners?

Yes, I believe that's what they'd prefer.

Also, I have a workaround (I'm currently just running ruff by way of pre-commit); and as such, I'm not sure I need this after all.

Thats also how I do it to make sure I am using the exact same config locally and on CI. Feel free to ping me if it turns out you do need this feature.

[mamercad]

For my understanding: It is easier for your security team to host ruff executables where they can be downloaded by this action rather than distributing them to the toolcaches on the hosted runners?

Yes, I believe that's what they'd prefer.

Also, I have a workaround (I'm currently just running ruff by way of pre-commit); and as such, I'm not sure I need this after all.

Thats also how I do it to make sure I am using the exact same config locally and on CI. Feel free to ping me if it turns out you do need this feature.

Yeah, I do pre-commit locally and in CI.