Skip to content

remote-build success message lists duplicate artifact names #1093

Open

Description

@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)

Activity

  1. steinbro commented on Jun 25, 2026

    @steinbro
    Member

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

  2. mr-cal commented on Jul 1, 2026

    @mr-cal
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions