-
Notifications
You must be signed in to change notification settings - Fork 3
SRE-3737 ci: HOT FIX - remove proxy related settings for Fault Injection testing stage #508
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
Merged
phender
merged 1 commit into
master
from
grom72/SRE-3737-no-proxy-for-Fault-Injection-testing
Apr 23, 2026
+16
−14
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
We should use an argument passed to dockerBuildArgs instead of triggering action based upon stage names.
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 think this is going be a phased approach, with the first just to get things working again, then the next to to work on a plan starting with documenting how external resources should be accessed in a portable and maintainable manner.
The first option to look for is if there is a Artifact server to be used, and we need to make the use of Artifactory or Nexus to be transparent. Which means we also need to have that set up for proxy mirroring. This gives the best performance and reliability for our lab.
It needs to be optional so that the code will work outside of our lab. And the code exposed to the user should hide if Artifactory or Nexus is used. This will a bit of planning and refactoring to roll in correctly.
Next option is that the code should be looking for a proxy is configured to be used, and that gets more complicated because the "noproxy" environment variable is unreliable to use. This is an option to support smaller volume shops.
For both these options we want to look for global configuration files that can be configured early in the script or node setup. Use of proxy environment variables should be avoided in production if at all possible because they have too broad of scope, and "noproxy" may not be sufficient to work around that issue. On a desktop system we can have a script look up the proxy server to do this configuration portably because that is how the proxy for a web browser is typically configure. Unknown if this discovery would work in the lab.
And then the final case where there are known specific proxy or artifact server used, such as a GitHub hosted runner, then we fall back to assuming direct access to the public Internet.