canonical / canonical/fetch-service

Unable to disambiguate CRAFT package type with multiple CRAFT YAMLs

Open
#296 0 comments 1 reaction 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.