Update store metadata

store
1

Hola!

We have recently introduced some changes allowing a developer to use snapcraft to update certain snap details in the store (or as we call it, metadata).

Through snapcraft push-metadata (available since 2.39), snapcraft will try to update the snap information in the store using the data in your snapcraft.yaml. The currently supported fields are summary, description and icon. A normal invocation will look like:

$ snapcraft push-metadata mysnap_3_amd64.snap
Pushing metadata from mysnap_3_amd64.snap
The metadata has been pushed

The developer can also update the store metadata using any revision as input:

$ snapcraft push-metadata mysnap_1_amd64.snap
Pushing metadata from mysnap_1_amd64.snap
The metadata has been pushed

In the same way, builds pushed from snapcraft, Launchpad or build.snapcraft.io will transparently update the store details when uploading a new revision.

Note, these fields will be updated only if they have not been subsequently edited using the store web UI (https://dashboard.snapcraft.io). When web edits have been made, snapcraft will detect the conflict and return a warning:

$ snapcraft push-metadata mysnap_2_amd64.snap
Pushing metadata from mysnap_2_amd64.snap
Metadata not pushed!
Conflict in 'description' field:
    In snapcraft.yaml: 'Description to be pushed.'
    In the Store:      'Current description in the store.'
You can repeat the push-metadata command with --force to force the local values into the Store

Why is this conflict warning useful? If someone else in your team is managing snap promotion information in the Store, you don’t want to override the changes made by them without noticing it. In the event of a conflict, you could update your snapcraft.yaml to reflect the changes made in the store, or force the update, overriding the store changes with your snap data. Here’s an example of overriding:

$ snapcraft push-metadata mysnap_2_amd64.snap --force
Pushing metadata from mysnap_2_amd64.snap
The metadata has been pushed

If there are no conflicts, or conflicts are cleared (because of a previous forced update, or because snapcraft.yaml values are updated to match the existing values in the store), subsequent pushes will proceed without warning.

If you are using snapcraft from the snap, you already have 2.39 around. If you didn’t switch to the snap version yet, you should install it and always have the latest snapcraft:
$ snap install snapcraft --classic

We hope you find this enhancement useful, let us know if you have any questions!

3 Likes
2

If I do encounter a situation where e.g. the description has been updated store side, and snapcraft detects the conflict, is there a way of automatically updating my local metadata with the store version (similar to bzr resolve --take-theirs or git merge --strategy-option theirs)?

3

Right now there isn’t a command or option to do that, but it should be possible to implement. For now, you would need to manually update your local yaml.
Maybe @sergiusens could share his thoughts about introducing the functionality.

4

Given that the whole feature thought out to use data from a snap and not specifically a source project, it wouldn’t feel bidirectional to allow for that. Given that most of the metadata these days gets constructed (or can get) from additional source during a build it seems like a hard task to reverse a build to get this done correctly.

5

I don’t understand how that’s relevant? Perhaps we’re misunderstanding each other.

What I’m asking for is that: given the metadata for a snap has been updated in the store via the web UI, and snapcraft detects a conflict, I can easily update my local snapcraft.yaml with the updated metadata e.g. description from the store.

6

The description field in snapcraft.yaml is no longer mandatory and can be picked from other sources of information (e.g.; appstream, setup.py) as explained on https://github.com/elopio/snappy-docs/blob/c8b1e1affaa26aa74e44813ec292fef22f928735/build-snaps/other-metadata.md

1 Like
7

This is not common knowledge. The referenced document currently sits in @elopio’s branch rather than the main docs repo and site. The PR is also marked as “don’t merge”. All these factors mean that this really isn’t as discover-able as you might think.

8

I am stating why it cannot be a two way avenue, I am not telling people to use this feature as it is still under review.

The adopt-info feature has been discussed on the forum (Extracting existing data from projects to feed into snap.yaml), the doc is not merged as it mentions features not yet available for consumption. However, the available features were announce https://github.com/snapcore/snapcraft/releases/tag/2.38

We want the full story before the documentation reaches general availability.

1 Like
9

@sergiusens We actually discussed and agreed to do exactly this in the original sprint in London where we came up with the current design. We also agreed that it wouldn’t be done at first while we worked on the underpinnings, but it would be a logical next step.

But from your response to @sparkiegeek and @lucyllewy above, it sounds like you’re saying this is by-design not supported. Do I misunderstand what you are actually saying? If so, it sounds like other people misunderstand it too.

10

Ok, I dug down on the notes and found Development sprint June 26th, 2017 (I wasn’t part of that sprint though).

It is technically possible to implement, I just think we need to be careful with the user story now that we have adopt-info. As an example, we need to figure out good ways to sync a conflict with an icon changed store side if said icon comes from appstream.

There is also the set-<keyword> work which would affect this. if at anytime in a build someone could say set-description $(cat file-during-build) it would be really hard to sync that in from the store.

Given that we are meeting live in a couple of weeks, I would welcome a discussion there on how to follow up on it.

11

Indeed, and to be clear that feature was not specified at all. It was literally a “Yeah, and we can do that afterwards”. We can specify it now, though.

I propose the following: we do not sync any third-party data. We don’t want to be in the business of editing arbitrary file formats and fiddling with people’s build systems in potentially dangerous ways.

What snapcraft offers is to sync up to the store, potentially adopting (reading) data from third-party formats, to warn on divergences, and then optionally and explicitly (when requested) to sync down to snapcraft’s native metadata format.

I don’t get that point. People really shouldn’t do that in the first place, since that means building a patch release for an old snapcraft.yaml will update the latest metadata from an old version of the content. But it doesn’t look like that’s what you’re referring to either?