-
Notifications
You must be signed in to change notification settings - Fork 339
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 @actions/github as a wrapper around octokit in order to support proxies #100
Changes from 5 commits
0086c2e
f77ab09
07caa0f
13ee335
8a6b404
b6efd2e
ca775cf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I'm entirely happy with this value having to include
github-production-release-asset-2e65be.s3.amazonaws.com
. This is a consequence of /~https://github.com/actions/http-client/blob/master/proxy.ts (which we use for downloading the codeql-bundle) not supporting any form of wildcards, so the domain has to be explicit. Maybe this is fine if this domain is for all of github, but I'm worried about it changing when we update the bundle, or just at random.The options that I see at the moment are to just not include this test, or to go with this hardcoded value and raise a PR on /~https://github.com/actions/http-client to improve support there.
@chrisgavin or @tibbes, do you have any thoughts here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does seem a little bit dodgy.
Perhaps another option is to use mitmproxy with a script that blocks everything except S3 URLs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After more thought and trying to get this working, I think in fact it's more fair to say that we only partially support
no_proxy
. As far as I can tell there isn't really a format spec for this, but more a general convention between implementations, and the one we're using seems to be on the minimal side.I'm going to remove this test and instead open an issue to improve this support and add the test back in.