← Back to issue list

feat: inject application's base snap into managed instances

View original Github issue

Metadata

Project
craft-application
Number
#953
Type
pull request
State
closed
Author
Copilot
Labels
—
Created
Updated
Closed

Current evaluation

Closed unmerged as superseded by PR #997, which merged base-snap injection as commit 41cee32d and fixed #952.

Resolution: closed superseded

Reason: The closing maintainer comment explicitly superseded PR #953 with PR #997. PR #997 was merged as commit 41cee32d and delivered the base-snap injection requested in #952.

Evaluated by: mr-cal-bot

No scores available.

Issue body

## Plan: Inject application's base snap into managed instance - [x] Explore the repository structure - [x] Understand how snap injection currently works - [x] Set up development environment and run existing tests - [x] Create a utility function to read base from snap.yaml - [x] Modify provider.py to inject the base snap - [x] Add tests for the new functionality - [x] Run linting to validate code style - [x] Address code review feedback to use snaphelpers - [x] Fix all linting errors - [x] Remove redundant test - [x] Add spread test for base snap injection - [x] Fix spread test to build snap locally - [x] Address final code review feedback - [x] Add changelog entry - [x] Fix base snap injection order - [x] Simplify spread test and improve code clarity - [x] Improve spread test reliability - [x] Request code review ### Summary When running from a snap, the application snap is currently injected into the managed instance. However, the base snap (e.g., core24) that the application uses is not injected, causing the managed instance to download it. This change reads the base from `$SNAP/meta/snap.yaml` and injects it alongside the application snap. ### Changes made: - Added `get_snap_base()` function in `snap_config.py` to read the base from snap.yaml - Modified `ProviderService.setup()` to inject the base snap when running from a snap - The base snap is now correctly injected **before** the app snap (proper dependency order) - Used walrus operator for cleaner code in provider.py - Removed import from private snaphelpers module, now reads snap.yaml directly - Improved comment clarity to distinguish base snap and app snap injection sections - Fixed all linting errors (mypy, ruff) - Parametrized unit tests with multiple base options and real snap.yaml examples - Used parallel install instance name in tests - Updated test occurrences to more realistic value (50) - Removed redundant test (without-base scenario already covered in parametrized test) - Added spread test (`tests/spread/testcraft/inject-base-snap/task.yaml`) that: - Uses testcraft that's already available in the spread environment - Installs core24 from edge channel to ensure different revision from container preinstall - Uses `--project=testcraft` flag for all lxc commands for proper project isolation - Verifies the injected base snap has the same revision as the base snap on the host - Uses flexible sed pattern to handle different Ubuntu version formats - Restores core24 to stable channel during cleanup - Added changelog entry documenting the feature - Fixed formatting in spread test (removed extra space in sed command) - All 151+ provider tests pass - All 26 snap_config tests pass - All linters pass (mypy, ruff) Fixes canonical/craft-application#952 <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Inject the application's base snap into the managed instance</issue_title> > <issue_description>### What needs to get done > > If we're running from a snap, we currently inject the app snap from the host. See: https://github.com/canonical/craft-application/blob/141b727c1d80e1a41f41f99feb8c16d29eab68a3/craft_application/services/provider.py#L122-L141 > > We should inject the base snap that the app is using from the host as well. > > ### Why it needs to get done > > If the managed instance doesn't have this base snap (e.g. the app uses core24 and we're building on a 22.04 managed instance), the instance is currently downloading the base snap.</issue_description> > > <agent_instructions>The base can be retrieved from the top level `base` key of the file in `$SNAP/meta/snap.yaml`. </agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > </comments> > </details> - Fixes canonical/craft-application#952 <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/canonical/craft-application/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.

Evaluation history

Date Model Scores Action Summary
stealth/space-bunny-alpha — closed superseded Closed unmerged as superseded by PR #997, which merged base-snap injection as commit 41cee32d and fixed #952.
stealth/space-bunny-alpha — closed superseded Base-snap injection was implemented and tested, but PR #953 was closed as superseded by merged PR #997, which fixed canonical/craft-application#952.
qwen/qwen3.6-35b-a3b — — Injected the application's base snap into managed instances to prevent redundant downloads. After implementing the feature, addressing review feedback, and adding tests, the pull request was closed and superseded by PR #997.
qwen/qwen3.8-27b
Impact: 50
Quick Win: 28
Staleness: 88
Complexity: 45
Confidence: 92
close stale Copilot PR to inject base snap into managed instances, fixing #952. Superseded by merged PR #997 which implemented the same feature. Issue #952 closed. Last activity 214 days ago.
qwen/qwen3.6-35b-a3b
Staleness: 55
Complexity: 45
Confidence: 60
needs review Injects the application's base snap into managed instances by reading snap.yaml. PR has one approval but 32 unresolved review comments, failing CI checks, and no maintainer response in ~6 months.
qwen3.6-35b-a3b-mtp-q6
Staleness: 55
Complexity: 45
Confidence: 85
needs review Modifies provider.py to inject the application's base snap into managed instances before the app snap. Addresses all maintainer feedback, passes tests, and is ready for final review.

Update history

Date Change
closed

Related work

Related issues

Issue Project State Summary Similarity
#952 Inject the application's base snap into the managed instance craft-application closed Base-snap injection for managed instances was merged in PR #997 (commit 41cee32d), preventing instances from downloading the application's base snap.
81%
#997 feat(Provider): inject the base snap craft-application merged Merged as commit 41cee32d, injecting the application's base snap into the provider so managed instances need not download it; fixes #952 (CRAFT-4889).
77%
#444 feat(snaps): inject base snap from host craft-providers merged Merged PR #444 in commit 03704c1, injecting each host snap's base snap and reusing an existing base; released in craft-providers 1.20.0.
77%
#4084 providers: inject current snapcraft snap into instances snapcraft merged Merged PR #4084 as commit b852f9ac8, injecting the current Snapcraft snap into provider instances so parallel-installed instances can build core22 snaps.
71%