Skip to content

Release Builders: Don't rebuild artifacts if the engine hasn't changed #173665

@jtmcdole

Description

@jtmcdole

Current pre-release: 3.36.0

Image
  • The first commit it the tree needs to build the content hash artifacts because it's the start of a new release.
  • The second commit is a cherry pick to framework-only changes.

Release engineers do not need to wait for the engine builds in Linux flutter_release_builder and instead skip ahead to the docs creation.
They could also immediately run post submit tests for this build. This could be a huge time saver for release engineers.

How can we know if we need to build the engine if we cannot look up builds in firestore?

  • If the commit has no changes for the same files that are checked in content_aware_hash
  • If the content hash doesn't change between current commit and previous (HEAD^)
  • Something else not yet considered

This could lead to an interesting case that multiple cherry picks are made at the same time, and release builds are not allowed to complete. In these cases, the release engineer would need to re-run the stopped build for the last engine change or any change that has the same content_aware_hash (because they are all uploaded to the same place).

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work listinfra: releaseRelease-related requests and toolingteam-infraOwned by Infrastructure teamtriaged-infraTriaged by Infrastructure team

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions