Skip to content

Conversation

@runningcode
Copy link
Contributor

@runningcode runningcode commented Nov 10, 2025

Extracts tooling version information (sentry-cli, Fastlane plugin, Gradle plugin) from uploaded artifact zip files and sends them to Sentry for database storage.

  • Adds _parse_metadata_content function to parse the metadata file format:
    • sentry-cli-version: X.Y.Z
    • sentry-fastlane-plugin: X.Y.Z
    • sentry-gradle-plugin: X.Y.Z

Refs: EME-606

Related PRs:
getsentry/sentry#103062
getsentry/sentry#104846
getsentry/sentry-cli#2994

@linear
Copy link

linear bot commented Nov 10, 2025

@codecov
Copy link

codecov bot commented Nov 10, 2025

Codecov Report

❌ Patch coverage is 95.69892% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.01%. Comparing base (7551f63) to head (0a59a68).
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
src/launchpad/utils/metadata_extractor.py 89.18% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #464      +/-   ##
==========================================
+ Coverage   80.92%   81.01%   +0.09%     
==========================================
  Files         164      166       +2     
  Lines       14248    14341      +93     
  Branches     1505     1508       +3     
==========================================
+ Hits        11530    11619      +89     
- Misses       2148     2152       +4     
  Partials      570      570              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

runningcode and others added 5 commits December 10, 2025 14:09
Extract sentry-cli, fastlane, and gradle plugin versions from artifact
metadata files and send them to Sentry's preprod artifact update API.

Changes:
- Add sentry_cli_version, fastlane_version, and gradle_plugin_version
  fields to UpdateData model
- Add _extract_tooling_versions method to parse .sentry-cli-metadata.txt
- Update _prepare_update_data to extract and include version information
- Add comprehensive tests for version extraction

Refs: EME-606
Moves tooling metadata extraction from artifact_processor into the
platform-specific analyzers where app_info is created. This better
encapsulates the metadata extraction logic and makes it more consistent
with other app_info field population.

Also renames sentry_cli_version to cli_version for consistency with
the metadata file format.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Removes comments that simply restate what the code is doing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Makes field naming consistent by using "plugin_version" suffix for both
fastlane_plugin_version and gradle_plugin_version.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Updates the metadata file keys to be more explicit:
- fastlane-plugin -> fastlane-plugin-version
- gradle-plugin -> gradle-plugin-version

This makes the key names more descriptive and consistent.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@runningcode runningcode force-pushed the no/eme-606-extract-and-send-tooling-versions branch from 1281aa7 to 0cfd711 Compare December 10, 2025 13:09
runningcode and others added 2 commits December 10, 2025 16:01
Removed duplicate metadata extraction logic from artifact_processor.py
since the tooling versions are already extracted by the platform analyzers
using the dedicated metadata_extractor.py utility. The values are available
via the app_info object, eliminating the need for redundant extraction.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changed extract_metadata_from_zip to only check for .sentry-cli-metadata.txt
in the root of the zip file, not in nested paths. This ensures we only find
one metadata file and makes the behavior more predictable.

Updated tests to verify that nested metadata files are ignored.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
android_app_info=android_app_info,
dequeued_at=dequeued_at,
cli_version=app_info.cli_version,
fastlane_plugin_version=app_info.fastlane_plugin_version,
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 I see a point of setting these here if you're already setting them in the apple_app_info/android_app_info - I'd recommend only one spot or the other

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does seem redundant but it doesn't work without both changes.
This line takes the data from the AndroidAppInfo and AppleAppInfo and turns it in to the UpdateData in order to send it to the artifact update API. See the sentry PR here: getsentry/sentry#103062

I wasn't sure if your question was about the inheritance of the objects but both UpdateData and BaseAppInfo inherit from BaseModel so there isn't a shared base.

but maybe I am misinterpreting your question?

Copy link
Member

@rbro112 rbro112 Dec 11, 2025

Choose a reason for hiding this comment

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

apple_app_info and android_app_info are already top-level fields in the UpdateData model. You also have reference to those in the backend. In this case, you're still duplicating the fields, cli_version, fastlane_plugin_version and gradle_plugin_version. Those can and should be pulled from only one spot or another (top-level in UpdateData or in apple/android_app_info), not duplicated.

IMO there should be a PR here to update the backend handling to get those values from the android/apple_app_info fields and we should remove the top-level fields from UpdateData. Simpler and leverages the app_info models that are already being passed, and we don't duplicate data.

Copy link
Contributor Author

@runningcode runningcode Dec 12, 2025

Choose a reason for hiding this comment

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

Ok I see. I misinterpreted this. I think I got it correctly. I added the tooling fields to apple_app_info and android_app_info and created a backend PR to accept these fields like this as well getsentry/sentry#104846

There is still the duplication when we need to copy from the models to the api models but I think that is what you expected.

runningcode and others added 2 commits December 11, 2025 09:44
Removed docstrings that repeated what the code already expressed through
clear function names and type hints. Kept only the format example in
_parse_metadata_content as it provides useful context.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix indentation in docstring to match ruff formatting rules.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@runningcode runningcode force-pushed the no/eme-606-extract-and-send-tooling-versions branch from 07f53e7 to 76cdd8e Compare December 12, 2025 10:16


class AppleAppInfo(BaseModel):
class BaseAppInfo(BaseModel):
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 this base class to reduce duplication of the cli_version. Can remove if it seems redundant.

certificate_expiration_date=app_info.certificate_expiration_date,
missing_dsym_binaries=app_info.missing_dsym_binaries,
build_date=app_info.build_date,
cli_version=app_info.cli_version,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cli_version could alternatively be moved to update_data to reduce duplication. thoughts?

@runningcode runningcode requested a review from rbro112 December 12, 2025 16:48
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.

3 participants