Improve connection tests by mbg · Pull Request #3853 · github/codeql-action (original) (raw)
A few minor improvements to the private registry connection checks:
- Use
GETinstead ofHEADrequests, for better compatibility. Some registries don't likeHEADrequests. We still callres.destroy()immediately after inspecting the status code, so never read the response body. So usingGEToverHEADshould have a minimal impact on performance. - For NuGet feeds, we now test the service index instead of the base URL. The service index should always be present and is more reliable than making a request to the base URL.
- Some logging improvements.
Risk assessment
For internal use only. Please select the risk level of this change:
- Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.
Which use cases does this change impact?
Workflow types:
- Managed - Impacts users with
dynamicworkflows (Default Setup, Code Quality, ...).
Products:
- Code Scanning - The changes impact analyses when
analysis-kinds: code-scanning. - Code Quality - The changes impact analyses when
analysis-kinds: code-quality. - Other first-party - The changes impact other first-party analyses.
Environments:
- Dotcom - Impacts CodeQL workflows on
github.comand/or GitHub Enterprise Cloud with Data Residency. - GHES - Impacts CodeQL workflows on GitHub Enterprise Server.
How did/will you validate this change?
- Unit tests - I am depending on unit test coverage (i.e. tests in
.test.tsfiles). - End-to-end tests - I am depending on PR checks (i.e. tests in
pr-checks).
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
- Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.
How will you know if something goes wrong after this change is released?
- Telemetry - I rely on existing telemetry or have made changes to the telemetry.
- Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
- Alerts - New or existing monitors will trip if something goes wrong with this change.
Are there any special considerations for merging or releasing this change?
- No special considerations - This change can be merged at any time.