-
Notifications
You must be signed in to change notification settings - Fork 438
Refactor offline bits out of Features class and use for CCR
#3477
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
base: main
Are you sure you want to change the base?
Conversation
It doesn't need to be in there since it doesn't depend on the API itself and call `getDefaultCliVersionFromFlags` directly
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.
Pull request overview
This PR refactors feature-flag evaluation to support CCR by splitting feature checks into an offline-only implementation and an API-backed implementation, and updating actions/tests to initialize feature flags via a new initFeatures factory.
Changes:
- Refactor
FeaturesintoOfflineFeatures(local checks only) andFeatures(local + GitHub API), and introduceinitFeaturesto select the implementation at runtime (CCR vs non-CCR). - Update action entrypoints to call
initFeaturesinstead of directly constructingFeatures, and type some usages againstFeatureEnablement. - Add unit tests covering
initFeaturesselection behavior and update existing tests to use the factory.
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/feature-flags.ts | Introduces OfflineFeatures, changes Features to extend it, and adds initFeatures factory for CCR-aware initialization. |
| src/upload-sarif-action.ts | Switches feature-flag initialization from new Features(...) to initFeatures(...). |
| src/start-proxy-action.ts | Switches to initFeatures(...) and types features as FeatureEnablement. |
| src/setup-codeql-action.ts | Switches feature-flag initialization to initFeatures(...). |
| src/init-action.ts | Switches to initFeatures(...) and types features as FeatureEnablement. |
| src/init-action-post.ts | Switches feature-flag initialization to initFeatures(...). |
| src/analyze-action.ts | Switches feature-flag initialization to initFeatures(...). |
| src/autobuild.ts | Switches feature-flag initialization to initFeatures(...) for the C++ autobuild feature check. |
| src/feature-flags.test.ts | Adds tests for initFeatures and updates setup helper to use the factory. |
| src/diff-informed-analysis-utils.test.ts | Updates test to construct features via initFeatures(...). |
| lib/upload-sarif-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/start-proxy-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/setup-codeql-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/init-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/init-action-post.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/autobuild-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
| lib/analyze-action.js | Generated JS updated to reflect TS refactor and new initFeatures. |
a956059 to
ff5f7af
Compare
ff5f7af to
7c91acf
Compare
This PR accomplishes two things:
FeaturesintoOfflineFeaturesandFeatures:OfflineFeaturesimplements theFeatureEnablementinterface and handles implements all feature checking that does not involve the GitHub API.FeaturesextendsOfflineFeaturesand combines the logic fromOfflineFeatureswith aGitHubFeatureFlagsinstance to query the GitHub API.FeatureEnablementimplementation withinitFeatures:OfflineFeaturesandFeaturesare no longer exported and insteadinitFeaturesmust be used.initFeaturesinstantiates aFeaturesinstance.OfflineFeaturesinstance instead.Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
dynamicworkflows (Default Setup, CCR, ...).Products:
analysis-kinds: code-scanning.analysis-kinds: code-quality.upload-sarifaction.Environments:
github.comand/or GitHub Enterprise Cloud with Data Residency.How did/will you validate this change?
.test.tsfiles).pr-checks).If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist