test-metro-locally

Publishes local Metro builds to Maven Local and verifies them in downstream Gradle projects.

1.4k|106|Updated Nov 5, 2024
One-click install
npx skills add https://github.com/ZacSweers/metro --skill test-metro-locally
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-metro-locally
Source: https://github.com/ZacSweers/metro/tree/main/.agents/skills/test-metro-locally
Command: npx skills add https://github.com/ZacSweers/metro --skill test-metro-locally

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Testing an unreleased Metro compiler or Gradle plugin change against a real consumer project is error-prone: stale artifacts, wrong repository ordering, and cached outputs can hide whether the fix actually works. This Skill provides a disciplined workflow for publishing a uniquely-versioned Metro build to Maven Local and verifying it downstream.

Core Features & Use Cases

  • Unique local publishing: Derives a task-specific version from VERSION_NAME and publishes via ./metrow publish --local, avoiding partial or reused artifacts.
  • Consumer configuration: Adds mavenLocal() to plugin and dependency repositories and points the consumer at the unique version without disturbing unrelated build settings.
  • Verified resolution: Confirms via buildEnvironment and dependencyInsight that the exact local version was selected, and reports baseline versus local outcomes per Metro mode.
  • Use Case: A contributor fixes a Metro FIR code generation bug reported in a GitHub issue, publishes 1.4.0-2587-20260725-LOCAL01 to Maven Local, and reruns the reporter's failing Gradle task to confirm the fix.

Quick Start

Ask the assistant to publish this Metro checkout to Maven Local and verify the change in your downstream reproducer project.

Frequently Asked Questions about test-metro-locally

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a local Metro build in another project?

Publish Metro to Maven Local with ./metrow publish --local --version <unique-version>, add mavenLocal() to the consumer's plugin and dependency repositories, set the Metro plugin version to the unique version, then rerun the consumer's original Gradle task.

Why should I use metrow instead of publishToMavenLocal?

The metrow wrapper supplies Metro's required publishing options, disables release signing, excludes documentation generation, and reruns publication tasks. Calling publishToMavenLocal directly can produce incomplete or incorrectly configured artifacts.

How do I confirm Gradle resolved the local Metro version?

Run ./gradlew buildEnvironment and dependencyInsight for dev.zacsweers.metro on compileClasspath and kotlinCompilerPluginClasspathMain. Verify the plugin marker plus compiler, runtime, and interop artifacts all resolve to the unique local version.

Why does my downstream test still use the old Metro version?

Gradle may cache plugin resolution or compiled outputs. Ensure mavenLocal() precedes remote repositories in pluginManagement, use a fresh unique version rather than reusing one, and only apply --rerun-tasks when stale outputs are suspected.

Should I use --rerun-tasks when testing incremental compilation issues?

No. When verifying an incremental compilation issue, do not use --rerun-tasks in subsequent runs because it forces full recompilation and masks the incremental behavior under test. Prefer publishing another unique local version instead.