Skip to content
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

Merged
merged 27 commits into from
Jun 2, 2023
Merged

Update engine build config docs. #41468

merged 27 commits into from
Jun 2, 2023

Conversation

godofredoc
Copy link
Contributor

  • Removed sections relevan only to a design doc.
  • Remove deprecated properties.
  • Add docs about default properites.
  • Rephrased some sections.

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

* Removed sections relevan only to a design doc.
* Remove deprecated properties.
* Add docs about default properites.
* Rephrased some sections.
Copy link
Member

@zanderso zanderso left a 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.

ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
* **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.
Copy link
Member

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.

Copy link
Contributor Author

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.

ci/builders/README.md Outdated Show resolved Hide resolved

```yaml
"archives": [
Copy link
Member

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.

Copy link
Contributor Author

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.

godofredoc and others added 13 commits May 4, 2023 15:51
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>
@chinmaygarde
Copy link
Member

Seems like this is still WIP. Please ping @zanderso once this is ready for re-review.

@chinmaygarde chinmaygarde added the Work in progress (WIP) Not ready (yet) for review! label May 18, 2023
@chinmaygarde
Copy link
Member

@zanderso @godofredoc Perhaps we can land just the parts that are complete?

@godofredoc
Copy link
Contributor Author

@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.

godofredoc and others added 10 commits May 25, 2023 17:15
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>
@godofredoc godofredoc removed the Work in progress (WIP) Not ready (yet) for review! label May 26, 2023
@godofredoc
Copy link
Contributor Author

All the comments have now been addressed and the suggestions have been applied.

Copy link
Member

@zanderso zanderso left a 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.


## 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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
Copy link
Member

@zanderso zanderso May 26, 2023

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.

include path **"out/host\_debug/zip\_archives/linux-x64/artifacts.zip"**
before uploading to GCS, e.g.
&lt;bucket&gt;/flutter/&lt;commit>/linux-x64/artifacts.zip.
* **Type:** - the type of storage to use. Currently only **“GCS”** and
Copy link
Member

@zanderso zanderso May 26, 2023

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.

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`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even on Windows?

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Member

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.

ci/builders/README.md Outdated Show resolved Hide resolved
ci/builders/README.md Outdated Show resolved Hide resolved
@godofredoc
Copy link
Contributor Author

Thanks for all the updates. Just a few more comments/questions.

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
Copy link
Contributor

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)
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

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.'

Copy link
Contributor

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?

ricardoamador
ricardoamador previously approved these changes Jun 1, 2023
Copy link
Contributor

@ricardoamador ricardoamador left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@zanderso zanderso left a 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.


## 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.
Copy link
Member

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 Show resolved Hide resolved
include path **"out/host\_debug/zip\_archives/linux-x64/artifacts.zip"**
before uploading to GCS, e.g.
&lt;bucket&gt;/flutter/&lt;commit>/linux-x64/artifacts.zip.
* **Type:** - the type of storage to use. Currently only **“GCS”** and
Copy link
Member

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.

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`.
Copy link
Member

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?

Copy link
Contributor

@ricardoamador ricardoamador left a 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.

@ricardoamador ricardoamador self-requested a review June 2, 2023 16:31
@ricardoamador ricardoamador dismissed their stale review June 2, 2023 16:32

The doc needs to be updated.

Copy link
Contributor

@ricardoamador ricardoamador left a 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

@godofredoc godofredoc merged commit e39bd7c into flutter:main Jun 2, 2023
29 checks passed
@godofredoc godofredoc deleted the update_docs branch June 2, 2023 19:58
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Jun 2, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Jun 2, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants