-
Notifications
You must be signed in to change notification settings - Fork 257
Update Kokoro config to include Wear #124
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
Conversation
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.
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
-
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. ↩
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.
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.
kokoro/gcp_ubuntu_docker/release.cfg
Outdated
| 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 |
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 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 theartifacts/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
kokoro/gcp_ubuntu_docker/release.cfg
Outdated
| 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 |
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.
kokoro/gcp_ubuntu_docker/release.cfg
Outdated
| # Example SBOM artifact for one of the filesets (adjust as needed) | ||
| fileset_artifacts { | ||
| container_name: "androidify_sbom" | ||
| artifact_globs: "artifacts/app-release.spdx.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.
garanj
left a comment
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.
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?
Edit Kokoro config to include WearOS build separately to generate unique attestation files