remote-build success message lists duplicate artifact names

[kirtisingh05]

Bug Description

Bug description

When remote-build is run multiple times, the success message lists
the same artifact filenames multiple times.

Root cause

artifact_downloads is a dict[url → path]. Different build runs
produce different URLs but the same filenames. Since deduplication
keys on URL, duplicate paths end up in .values(), causing the same
snap name to appear multiple times in the output.

Related

canonical/snapcraft#6230

To Reproduce

1. Run snapcraft remote-build on a core22 project with multiple architectures
2. Wait for build to complete
3. Run snapcraft remote-build again on the same project
4. Observe the success message artifact names are listed twice

part yaml

name: my-snap
base: core22
version: '0.1'
summary: test snap
description: test snap
grade: devel
confinement: devmode
architectures:
  - build-on: amd64
  - build-on: arm64
parts:
  my-part:
    plugin: nil

Relevant log output

Build completed.
Log files: ...
Artifacts: my-snap_0.1_amd64.snap, my-snap_0.1_arm64.snap, my-snap_0.1_amd64.snap, my-snap_0.1_arm64.snap

(same artifacts listed twice after running remote-build a second time)

[steinbro]

This is possibly related to #249 regarding cleaning up old remote builds.

[mr-cal]

I did some research and have a few takeaways.

1. Craft-application is downloading the same artifacts multiple times and overwriting it.
2. This only happens when there are no changes to the project source between builds. Theoretically, the artifacts would be identical, except for timestamps.

One possible solution would be filtering at retrieval time. Theoretically, launchpad returns builds ordered by date built, so craft-application could trust this ordering and only download the first (newest) copy of each build artifact.

The other possible solution would be to retrieve artifacts based on the build id. I think this is unique per build, so we could pass the id as a filter when getting the artifacts.

I haven't tested either solution, so I have no idea if they'd work. I like the latter solution, but I wonder if it's possible to do with asynchronous builds. We may have to cache the build id locally, if we're not already doing that.

I'd like to hear @lengau's opinion too.