canonical / canonical/fetch-service
Unable to disambiguate CRAFT package type with multiple CRAFT YAMLs
- Dominant language
- Go
- Stars
- 4
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
### Bug Description
If you provide multiple *craft YAMLs in a single *craft repo, the Fetch Service incorrectly assumes the "metadata.type" of the CRAFT package. For example, see the fetch service metadata for [this bin build](https://launchpad.net/~sd-admin-staging/sd-project/+craft/ubuntu.public.superalpaca-hello-world-2+latest-edge/+build/624/), and grep for `hello-world-2`; the matching sourcecraft repo is [here](https://git.staging.snapcraftcontent.com/ubuntu/public/sourcecraft/superalpaca-hello-world-2/tree/?h=latest_edge). The "metadata.type" for `superalpaca-hello-world-2` is "application/x.canonical.snapcraft" instead of "application/x.canonical.sourcecraft". I think that the Fetch Service should do one (or both) of:
1. Get the "metadata.type" and "metadata.name" from the download (git/CRAFT storage) URL if possible, since the YAML doesn't necessarily have to match these
2. Reject the CRAFT package if we're unable to disambiguate it's type
Here's the relevant output from the metadata JSON mentioned above:
The `response-inspection` shows:
```json
"craft.rockcraft": {
"opinion": "Approved",
"reason": "rockcraft repository found",
"annotations": {
"checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9"
}
},
"craft.snapcraft": {
"opinion": "Approved",
"reason": "snapcraft repository found",
"annotations": {
"checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9"
}
},
"craft.sourcecraft": {
"opinion": "Approved",
"reason": "sourcecraft repository found",
"annotations": {
"checkout": "07b14bd534988c05bef5f1bdbc4e834614a50ac9"
}
},
```
but the artefact metadata will just choose one of these
```json
"metadata": {
"type": "application/x.canonical.snapcraft",
"sha1": "f379734635d331dda7f52f01d334e11dd1cdf8cc",
"sha256": "7f741bc495d912e02223a73ff74ea6a4926982475fc1cfe689b7dc20788e9eab",
"size": 1396,
"name": "superalpaca-hello-world-2",
"version": "1",
"vendor": "",
"description": "Single-line elevator pitch for your amazing snap",
"author": "",
"license": ""
},
```
### To Reproduce
Not 100% sure of the exact steps, but it's something like:
1. Register a `sourcecraft` package
2. In the git repo for the package, create valid `sourcecraft.yaml`, `snapcraft.yaml` and `rockcraft.yaml` and commit them to the registered `sourcecraft` package in the Store
3. The builds for the package will trigger, wait for one of them to succeed
4. Get the Fetch Service Metadata JSON for this build, and it will show that multiple craft inspectors approved the package in the `response-inspection` when pulling in the `sourcecraft` package into the build (like in the Bug Description above)
### Relevant log output
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the Fetch Service metadata output with a registered sourcecraft package containing sourcecraft.yaml, snapcraft.yaml, and rockcraft.yaml. Trace how the response-inspection results become artefact metadata, then define done as selecting the type and name from the download URL or rejecting the package when the type cannot be disambiguated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100