feat(build): add CLI options for custom engine artifact sources #82
Conversation
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 --github-artifacts-repo, --github-artifacts-runid, --github-artifacts-engine-version, --github-artifacts-auth-token options - Parse options early in executable.dart before context setup - Support GITHUB_TOKEN env variable for workflow artifact authentication - Enable downloading engine artifacts from custom forks and workflow runs
ardera
approved these changes
Jan 25, 2026
Comment on lines
+39
to
+52
| // Helper to extract option value from args | ||
| String? _extractOption(List<String> args, String optionName) { | ||
| for (var i = 0; i < args.length; i++) { | ||
| final arg = args[i]; | ||
| if (arg == '--$optionName' && i + 1 < args.length) { | ||
| return args[i + 1]; | ||
| } | ||
| if (arg.startsWith('--$optionName=')) { | ||
| return arg.substring('--$optionName='.length); | ||
| } | ||
| } | ||
| return null; | ||
| } | ||
|
|
Owner
There was a problem hiding this comment.
this does the job, but it's a bit hacky
command parsing should be done inside the command, with the argParser. Two reasons:
- All the tests are done by calling FlutterpiCommandRunner with fake objects in the context. Since the logic here is outside of commands and the command runner, this is hard to test as it is right now.
- Harder to get the parsing wrong. (For example, your parser doesn't handle a user passing
--to terminate options, or a user passing--my-option-with-following-value --github-workflow-artifacts...(not that the latter would ever happen))
Maybe it's better to just add settable fields to the FlutterpiCache:
specifiedRepo, specifiedWorkflowRunId, specifiedAuthToken
And if e.g. workflow run id is set, source from workflow instead of releases.
That's a bit similar to how it's done for the device discovery.
IMO it's fine to leave away the auth token cmdline arg and just allow setting it via GH_TOKEN env var, if that makes implementation easier. And no need to differentiate here whether it's workflow / releases cache, GH_TOKEN is potentially useful for both.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Add CLI options to download engine artifacts from custom GitHub repositories and workflow runs, enabling testing of custom engine builds before they are officially released.
New options (hidden by default, shown with
--verbose)--github-artifacts-repo=<owner/repo>- Use a custom GitHub repository for engine artifacts--github-artifacts-runid=<run-id>- Download from a specific GitHub Actions workflow run--github-artifacts-engine-version=<hash>- Specify the engine version in the workflow artifacts--github-artifacts-auth-token=<token>- GitHub authentication token (also readsGITHUB_TOKENenv)Use cases
Example
Test plan