Skip to content

Conversation

@riggaroo
Copy link
Collaborator

@riggaroo riggaroo commented Sep 11, 2025

Edit Kokoro config to include WearOS build separately to generate unique attestation files

@riggaroo riggaroo requested a review from tiwiz as a code owner September 11, 2025 08:54
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Summary of Changes

Hello @riggaroo, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the artifact definition within the release.cfg file, transitioning from a broad, regex-based approach to a more structured and explicit system using fileset_artifacts. This change improves the organization and clarity of how different build outputs, including the main phone app AAB, the new Wear OS AAB, and SBOMs, are collected and stored in Google Cloud Storage.

Highlights

  • Refactored Artifact Definition: The previous generic artifact definition using action { define_artifacts { ... } } has been replaced with more granular fileset_artifacts { ... } blocks. This allows for more precise control over artifact grouping and storage.
  • Added Wear OS App Bundle (AAB) Support: A new fileset_artifacts block was introduced specifically for the Wear OS App Bundle (wear-release-signed.aab) and its associated attestation. These artifacts will now be stored in a dedicated wear_aab/ directory within the GCS bucket.
  • Explicit Phone App Bundle (AAB) Definition: The main phone app AAB (androidify-release-signed.aab) and its attestation now have their own explicit fileset_artifacts block, ensuring they are stored in the phone_aab/ GCS directory.
  • Dedicated SBOM Artifact Storage: A separate fileset_artifacts block has been added for the Software Bill of Materials (SBOM) file (app-release.spdx.json), directing it to the sboms/ GCS directory.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request updates the Kokoro release configuration to use fileset_artifacts, which allows for more granular control over build artifacts. This is used to separate the phone app, Wear OS app, and SBOM artifacts into different Google Cloud Storage destinations. The change is a good improvement, but it omits the strip_prefix and fail_if_no_artifacts properties that were present in the old configuration. My review includes suggestions to re-add these properties to ensure build robustness and maintain clean artifact paths in storage.

artifact_globs: "artifacts/androidify-release-signed.aab"
artifact_globs: "artifacts/androidify-release-signed.aab.intoto.jsonl" # Assuming attestation is named after the AAB
# Required to generate a unique attestation for this fileset
store_attestation: true
Copy link
Contributor

Choose a reason for hiding this comment

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

high

The previous define_artifacts configuration included strip_prefix: "artifacts" and fail_if_no_artifacts: true. These appear to have been omitted in the new fileset_artifacts block.

  • strip_prefix: This is useful to avoid storing artifacts with the artifacts/ path prefix in GCS.
  • fail_if_no_artifacts: This is important to ensure the build fails if an expected artifact is not found.

It's recommended to add these properties back for a more robust build process.

  store_attestation: true
  strip_prefix: "artifacts"
  fail_if_no_artifacts: true

artifact_globs: "artifacts/wear-release-signed.aab"
artifact_globs: "artifacts/wear-release-signed.aab.intoto.jsonl" # Assuming attestation is named after the AAB
# Required to generate a unique attestation for this fileset
store_attestation: true
Copy link
Contributor

Choose a reason for hiding this comment

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

high

This fileset_artifacts block for the Wear OS app is also missing strip_prefix: "artifacts" and fail_if_no_artifacts: true. For consistency and build robustness, please add them here as well.

  store_attestation: true
  strip_prefix: "artifacts"
  fail_if_no_artifacts: true

# Example SBOM artifact for one of the filesets (adjust as needed)
fileset_artifacts {
container_name: "androidify_sbom"
artifact_globs: "artifacts/app-release.spdx.json"
Copy link
Contributor

Choose a reason for hiding this comment

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

high

This fileset_artifacts block for the SBOM is missing strip_prefix: "artifacts" and fail_if_no_artifacts: true. Adding them will ensure consistent artifact storage and a more robust build process.

  artifact_globs: "artifacts/app-release.spdx.json"
  strip_prefix: "artifacts"
  fail_if_no_artifacts: true

@riggaroo riggaroo changed the title Update release.cfg to include Wear Update Kokoro config to include Wear Sep 11, 2025
@riggaroo riggaroo requested a review from garanj September 11, 2025 13:58
Copy link
Contributor

@garanj garanj left a comment

Choose a reason for hiding this comment

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

Looks good to me! I guess if any of the comments from Gemini about robustness are valid, they can be added once it's proven to work?

@riggaroo riggaroo merged commit 6d76ae4 into main Sep 11, 2025
4 checks passed
@riggaroo riggaroo deleted the wear-os-release branch September 11, 2025 14:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants