Specify where a Snap build was requested

This sounds like an ideal case for Revision Attributes, a feature not yet publicly released but with a basic initial implementation currently live and in use by the storefront for very similar use-cases.

https://docs.google.com/document/d/1nZA1aevK86kiJUo8EH5Ff8Zb71QLu0AhrvBzirmfp4Y/edit is an internal Google Doc with more detail.

Matias warns that the way to set them is currently a little tricky because it's not exposed for general use yet, and currently the tags are restricted to a predefined list, but this still feels very much like the (theoretically, at least) ideal solution.

It seems like the spec would need updating (will add a comment to the doc itself, but wanted to write it here too).

The thing we're interested in is what caused the build, currently it seems the spec just says "launchpad did it, at this time, from this git commit, at this time" What we're interested in is what caused launchpad to build the snap? For example "webhook from [url]" "manual build from [url]" etc.

I think there might be an easier way to inject this than revision attributes. Launchpad already sets SNAPCRAFT_IMAGE_INFO, which snapcraft honours; this lets us inject a dictionary that ends up in "image-info" in snap/manifest.yaml. At the moment we inject the Launchpad build request ID, the build request timestamp, and the build URL this way; we could perhaps add a "build-reason" or similar, though we'd need to specify it clearly.

Alternatively, does it need to end up in the snap store at all? Since the build URL is already tracked in the snap's manifest, we could have a property in the Launchpad database that describes why the build was triggered, and you could look it up from there.

One thing that would be helpful to know here is how you intend to look it up. (Is it purely informational, or does it affect how the service is run? If the latter, what information do you have available at the point when you're trying to do the lookup, and are there any other operational constraints?)

Hello Collin,

It will be nice to have a "build-reason" property in Launchpad, where we can store values like:
- "Manually trigger from user"
- "GitHub webhook from build.snapcraft.io"
- "GitHub webhook from snapcraft.io"
- "Poller script"

It will affect how the service run because we might want to notify the web users in the future if they are still using the build.snapcraft.io webhook. Since we can't update GitHub webhooks without the GitHub user token.

This feature doesn't need to end up in the snap store, but it will be nice to be able to access this property from the launchpad API.

Thank you!

(Hi - my name is Colin, not Collin, FWIW.)

Can you also say anything about what information you have available at the point when you're trying to do the lookup? Do you know the Launchpad identity of the snap in question?

Hi Colin, sorry for misspelling your name before.

Yes, at that point we will know the Launchpad Identity of the Snap, we can do an API call to get the builds (right now we are already making this call for another purpose).

For us, it will be useful to have the property not only when getting a build from the API also on each entity when we use the builds_collection_link from the snap.