fix: replace git reference injection with wheel artifacts in charm test workflows

[Copilot]

For our compatibility tests, instead of patching the dependencies to require the branch's version of ops[...] via a Git link, build local wheels from the branch and patch the requirements to use that. This avoids races where the appropriate revision of the branch is not yet available from the CI runner.

Changes:

• Create a reusable workflow to build ops wheels (ops, ops-scenario, ops-tracing)
• Update observability-charm-tests.yaml to use wheel artifacts instead of git references
• Update published-charms-tests.yaml to use wheel artifacts instead of git references
• Update db-charm-tests.yaml to use wheel artifacts instead of git references
• Update hello-charm-tests.yaml to use wheel artifacts instead of git references

• Fixes Our charm tests that inject ops from github branch sometime trip on git reference #1843

[tonyandrewmeyer]

@copilot the pack test can't use the wheels because the packing is done in a sandboxed environment. Please revert the changes to charmcraft-pack.yaml.

[Copilot]

@copilot the pack test can't use the wheels because the packing is done in a sandboxed environment. Please revert the changes to charmcraft-pack.yaml.

Reverted in d012d43. The charmcraft-pack.yaml workflow now uses the original git reference approach since the packing is done in a sandboxed environment that cannot access local wheel files.

[tonyandrewmeyer]

@copilot the observability tests are failing:

    # Get absolute paths to the wheels
    ops_wheel="$(echo "$(pwd)/operator-wheels/ops-*.whl")"
    ops_scenario_wheel="$(echo "$(pwd)/operator-wheels/ops_scenario-*.whl")"
    ops_tracing_wheel="$(echo "$(pwd)/operator-wheels/ops_tracing-*.whl")"
    # Add ops first, then ops-scenario (for testing), then ops-tracing
    uv add "${ops_wheel}" --raw-sources --prerelease=if-necessary-or-explicit
    uv add "${ops_scenario_wheel}" --optional dev --raw-sources --prerelease=if-necessary-or-explicit
    uv add "${ops_tracing_wheel}" --raw-sources --prerelease=if-necessary-or-explicit
  else
    echo "Error: no uv.lock file found"
    exit 1
  fi
  shell: /usr/bin/bash -e {0}
error: The dependency `ops-scenario` could not be found in `project.optional-dependencies.dev`
maybe ops-scenario is not a dev dependency
warning: The `requires-python` specifier (`~=3.10`) in `grafana-k8s` uses the tilde specifier (`~=`) without a patch version. This will be interpreted as `>=3.10, <4`. Did you mean `~=3.10.0` to constrain the version as `>=3.10.0, <3.11`? We recommend only using the tilde specifier with a patch version to avoid ambiguity.
Using CPython 3.12.3 interpreter at: /usr/bin/python3
Creating virtual environment at: .venv
error: The wheel filename "ops-*.whl" is invalid: Must have a Python tag
Error: Process completed with exit code 2.

[Copilot]

@copilot the observability tests are failing:

...

Fixed in d184690. Changed from echo "$(pwd)/operator-wheels/ops-*.whl" to ls operator-wheels/ops-[0-9]*.whl which properly expands the glob pattern. The echo command was passing the literal string "ops-*.whl" to uv instead of the actual filename.

[Copilot]

@copilot no, you pointed uv to the same Python, so the result is the same. Run uv pip freeze, do not tell it what Python to use.

Fixed in 2bbca32. Changed to use uv pip freeze without the --python flag, so uv will use its own managed environment and show the correct dependencies installed by uv run.

[tonyandrewmeyer]

@copilot let's work around this by having the observability tests (only, not the other workflows) force a newer version of interface tester. Something like uv add pytest-interface-tester>=3.4 but you might need to add other arguments or adjust to make sure that it's properly updated and used. We want at least version 3.4.

[Copilot]

@copilot let's work around this by having the observability tests (only, not the other workflows) force a newer version of interface tester. Something like uv add pytest-interface-tester>=3.4 but ...

Added workaround in c5f97df. The observability-charm-tests workflow now forces an upgrade of pytest-interface-tester to version >=3.4 using uv add "pytest-interface-tester>=3.4" --optional dev --upgrade after updating the ops dependencies. This should resolve the compatibility issues with the old version of interface-tester.

[Copilot]

Pull request overview

This PR replaces git reference injection with wheel artifacts in charm compatibility test workflows to avoid race conditions where git revisions might not be available immediately from CI runners.

Changes:

• Added a reusable workflow _build-wheels.yaml to build wheel artifacts for ops, ops-scenario, and ops-tracing packages
• Updated four test workflows (observability, published-charms, db-charm, hello-charm) to download and use wheel artifacts instead of git references
• Modified dependency patching logic in all workflows to reference local wheel files instead of git URLs

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
.github/workflows/_build-wheels.yaml	New reusable workflow that builds wheels for all workspace packages and uploads them as artifacts
.github/workflows/published-charms-tests.yaml	Updated to use wheel artifacts for both charm-tests and charmcraft-profile-tests jobs
.github/workflows/observability-charm-tests.yaml	Updated to use wheel artifacts including ops-tracing, added pytest-interface-tester upgrade step
.github/workflows/hello-charm-tests.yaml	Updated to download and use ops wheel artifact
.github/workflows/db-charm-tests.yaml	Updated to use wheel artifacts, removed unnecessary repository checkout step

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[james-garner-canonical]

The overall approach seems reasonable, and the workflows that run on PRs do appear to be working correctly with this approach. Could we get a run of the others (just published charm tests?) to verify those as well.

I do wonder if there's a simpler approach that could work. For example, what if the charm test workflows used actions/checkout to check ops out into a subdirectory (e.g. local_ops) and we just pointed their dependency files there instead of to Github?

[james-garner-canonical]

Is it problematic that we run this workflow multiple times (once for every workflow that shares a trigger) and upload the same artifact with the same name multiple times? Other than being a bit inefficient -- any correctness issues?

[tonyandrewmeyer]

I don't think there are correctness issues. With v4 and above artefacts get replaced and I believe that's atomic, so it's just inefficient.

We could have a single workflow that does the db-charm-tests, hello-charm-tests, observability-charm-tests. There's a reasonable amount of overlap there already and they are all doing roughly the same thing and the by-team organisation could just be within the workflow. Or a single workflow that's triggered that calls those workflows.

I don't think we'd want to combine those with the published-charms-tests one, though. In particular, that one is only run on a schedule and has a lot of regular failures (particularly at the moment with the Python version issue).

[james-garner-canonical]

Agreed on the published charm tests. Factoring the workflows differently could always be a separate PR later if we feel the need.

[tonyandrewmeyer]

The overall approach seems reasonable, and the workflows that run on PRs do appear to be working correctly with this approach. Could we get a run of the others (just published charm tests?) to verify those as well.

Sure.

I do wonder if there's a simpler approach that could work. For example, what if the charm test workflows used actions/checkout to check ops out into a subdirectory (e.g. local_ops) and we just pointed their dependency files there instead of to Github?

I went with the build wheels approach because:

• Scenario used to use this when it was in a separate repo.
• It's what's suggested in the linked issue.
• If you're not careful with how you lay out the clones and where you run things, you can accidentally end up running the ops tests (or static checking ops) as well as the downstream repo (I've seen this more than once).

None of those are super strong arguments for doing wheels over a local file, though.

Are you asking to switch to that, or are you ok with the wheel approach?

[james-garner-canonical]

Are you asking to switch to that, or are you ok with the wheel approach?

I'm OK with it assuming the other reviewer is too.