-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Update engine build config docs. #41468
Conversation
* Removed sections relevan only to a design doc. * Remove deprecated properties. * Add docs about default properites. * Rephrased some sections.
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.
Not sure I caught everywhere, but since the canonical home for the source is in GitHub, links to the code should be GitHub URLs rather than codesearch URLs.
Many small nits, but there are also several places where more details about options, their possible values, and their meanings would be helpful.
* **Parameters**, flags passed to the script. Both input and output paths must be relative to the checkout directory. | ||
* **Name** - the name of the step running the script. | ||
* **Parameters** - flags passed to the script. Both input and output paths must | ||
be relative to the checkout directory. | ||
* **Script**, the script path relative to the checkout repository. | ||
* **Language**, the script language executable to run the script. If empty it is assumed to be bash. |
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.
The bit about the default being bash
was missing from the description of the language
field above, I think.
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.
Added the default value description to the tests section.
|
||
```yaml | ||
"archives": [ |
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 a bit confused about how/why this differs from the archives
list in sub-builds. The archives
components in sub-builds had a lot more options. Do they need to also be referenced here at the top-level, or do they get captured automatically somehow? A more detailed description both here and there would be helpful.
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.
The archives section on the subbuilds is more complex because it supports scenarios like subbuilds uploading multiple jar and pom files to a bucket different from the one used for all the other archives and GN+ninja artifacts being generated directly inside the zip_archives folder of the build output.
The global generator use case is simpler because the script have full control about where inside src/out to generate the artifacts and also have the freedom to specify the path relative to the bucket where the artifact will be uploaded to.
I have a pending action item to move the archives inside the global generator configuration to make them simpler to understand and potentially remove complexity required during the migration.
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Seems like this is still WIP. Please ping @zanderso once this is ready for re-review. |
@zanderso @godofredoc Perhaps we can land just the parts that are complete? |
Let me update all the comments today and send it for a second review before the end of the day. |
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
Co-authored-by: Zachary Anderson <zanderso@users.noreply.github.com>
All the comments have now been addressed and the suggestions have been applied. |
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.
Thanks for all the updates. Just a few more comments/questions.
ci/builders/README.md
Outdated
|
||
## USAGE EXAMPLES | ||
|
||
Engine builds will be translated one to one using the build definition language with one file per build. The build definition files will be stored in the [flutter/engine/ci/builders](https://cs.opensource.google/flutter/engine/+/main:ci/builders/) directory. | ||
Engine build definition files using the Build Definition Language can be found in the | ||
[flutter/engine/ci/builders](https://cs.opensource.google/flutter/engine/+/main:ci/builders/) directory. |
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.
[flutter/engine/ci/builders](https://cs.opensource.google/flutter/engine/+/main:ci/builders/) directory. | |
[flutter/engine/ci/builders](https://github.com/flutter/engine/tree/main/ci/builders) directory. |
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.
Applied
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.
Not sure if it's a GitHub issue, but I'm still seeing the old URL.
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.
ok, I'll give up on pushing commit and update directly from the github ui. It seems like it is ignoring my changes.
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.
ok, updates are available now.
* **name:** - used to identify the archive inside CAS. | ||
* **base\_path:** - the portion of the path to remove from the full path before | ||
uploading to its final destination. In the example the above the | ||
base\_path **“out/host\_debug/zip\_archives”** will be removed from the |
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.
Is there any situation where you would not want to specify a base_path
? If not, and it always has to be specified, then why is it a configurable option? Could it be derived from one of the other options?
Yes, the use case is legacy files generated outside of zip_archives folder or files generated with the incorrect folder structure.
ci/builders/README.md
Outdated
include path **"out/host\_debug/zip\_archives/linux-x64/artifacts.zip"** | ||
before uploading to GCS, e.g. | ||
<bucket>/flutter/<commit>/linux-x64/artifacts.zip. | ||
* **Type:** - the type of storage to use. Currently only **“GCS”** and |
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.
The question is why would you choose one instead of the other. What's a situation where you'd choose CAS? What's a situation where you'd choose GCS?
Updated, using CAS will allow you to inspect the files during development without having to worry about cleanup on impacting production as they are automatically deleted after a few days of no use. GCS is expected for the final artifacts as it is the location the flutter tool will use to download them.
ci/builders/README.md
Outdated
Note that to keep the recipes generic they don’t know anything about what the test script is doing and it is the responsibility of the test script to copy the relevant files to the FLUTTER\_LOGS\_DIR directory. | ||
* **language** - the executable used to run the script, e.g. python3, bash. | ||
In general any executable found in the path can be used as language. The | ||
default value for this property is `bash`. |
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.
Even on Windows?
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.
Taking that comment back, default is empty which means script will be treated as executable with the assumption that already has the right permissions.
Bash can be used on all the platforms the caveat is the use of paths in the windows os wich will require something like /c/myfile.exe instead of c:/myfile.exe.
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.
Can you add that detail to the docs, please?
|
||
The test scripts will run in a deferred context (failing the step only after logs have been uploaded). The tester and builder recipes provide an environment variable called FLUTTER\_LOGS\_DIR pointing a temporary directory where the test runner can place any logs|artifacts needed to debug issues. At the end of the test execution the content of FLUTTER\_LOGS\_DIR will be uploaded to Google Cloud Storage before signaling the pass | fail test state. | ||
The test scripts will run in a deferred context (failing the step only after | ||
logs have been uploaded). Tester and builder recipes provide an environment |
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.
Might be good to note here to avoid confusion.
Updated! |
sub-builds to generate artifacts. | ||
* **Builder** - a combination of configuration, recipes and a given commit to | ||
build and test artifacts. | ||
* **Build** - a builder running with specific properties, repository and |
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.
So these two (builder and build) seem to be heavily overloaded. Build is specified a single top level build that displays in the flutter dashboard and is expressed as a single file containing multiple sub builds.
A builder is also referred to as the runner of this top level build and also a runner of a sub build, which we may want to specify somewhere in here. So builder refers to two different parts of an engine_v2 build.
|
||
``` | ||
The following is a sample build configuration referencing | ||
[android\_aot\_engine.json](https://github.com/flutter/engine/blob/main/ci/builders/mac_android_aot_engine.json) |
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.
nit: if we want to be explicitly clear we should note that you need to omit the .json extension here as the recipe knows that this is expected to be json.
|
||
The following is the high level structure of the build component: | ||
|
||
``` | ||
```yaml |
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.
nit: json not yaml.
is required `cas_archive": false,` needs to be added to the | ||
configuration. | ||
|
||
```yaml |
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.
nit: json not yaml.
The build definition language will force all the artifacts to be generated with GN+Ninja. This will require a carefully designed strategy to replace the artifacts with minimal disruption. | ||
Global tests follow the same format as build tests but defined at the top | ||
level. The main difference from local tests is that global tests have access | ||
to the sub-build artifacts. |
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.
nit: consider rephrasing 'to the sub-build artifacts.' as 'to all sub-build artifacts.'
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.
Now that I think about it, what would be the purpose of running the tests locally when they could just be specified as global? I guess if you do not need all the artifacts?
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.
LGTM
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.
Not sure if something is going wrong with GitHub, but it seems like some of the updates are missing.
ci/builders/README.md
Outdated
|
||
## USAGE EXAMPLES | ||
|
||
Engine builds will be translated one to one using the build definition language with one file per build. The build definition files will be stored in the [flutter/engine/ci/builders](https://cs.opensource.google/flutter/engine/+/main:ci/builders/) directory. | ||
Engine build definition files using the Build Definition Language can be found in the | ||
[flutter/engine/ci/builders](https://cs.opensource.google/flutter/engine/+/main:ci/builders/) directory. |
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.
Not sure if it's a GitHub issue, but I'm still seeing the old URL.
ci/builders/README.md
Outdated
include path **"out/host\_debug/zip\_archives/linux-x64/artifacts.zip"** | ||
before uploading to GCS, e.g. | ||
<bucket>/flutter/<commit>/linux-x64/artifacts.zip. | ||
* **Type:** - the type of storage to use. Currently only **“GCS”** and |
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.
Sorry, I don't see the update. Not sure if I'm just having problems with GitHub.
ci/builders/README.md
Outdated
Note that to keep the recipes generic they don’t know anything about what the test script is doing and it is the responsibility of the test script to copy the relevant files to the FLUTTER\_LOGS\_DIR directory. | ||
* **language** - the executable used to run the script, e.g. python3, bash. | ||
In general any executable found in the path can be used as language. The | ||
default value for this property is `bash`. |
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.
Can you add that detail to the docs, please?
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 needs more updating as there are fields that need to be included in this doc to better flush out the parts of each build.
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.
Approving since this follow up issue has been created to address a more detailed dive into each of the usable objects: flutter/flutter#128125
…128147) flutter/engine@b4250ac...f3f6a02 2023-06-02 jason-simmons@users.noreply.github.com Wrap concurrent message loop tasks in an autorelease pool on iOS/Mac platforms (flutter/engine#42459) 2023-06-02 godofredoc@google.com Update engine build config docs. (flutter/engine#41468) 2023-06-02 43054281+camsim99@users.noreply.github.com [Android] Bump unit test robolectric version to 4.10.3 (flutter/engine#42454) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC jonahwilliams@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.