cc @rayson

I agree it would be nice for each artifact to provide a unique id field, even it it a dupe of the data already there.

@happz I am just politely noting that container-image is for images build outside of OSBS, just to make you aware. See https://pagure.io/fedora-ci/messages/pull-request/18

@happz I am just politely noting that container-image is for images build outside of OSBS, just to make you aware. See https://pagure.io/fedora-ci/messages/pull-request/18

Ack, but that shouldn't matter - there is a property of an artifact which lets us tell which class artifact belongs to ("type"), and there should another field that lets us tell which of these artifacts we work with, and I believe, in the sake of simplicity, readability, and future generations :) the field should keep its name across different artifacts types no matter what's the actual value (simple integer, complex NVR-like strings, etc.) It'd be a mess if consumers would need to check different field for each and every of N different artifact types :(

Thanks for the link - according to https://pagure.io/fedora-ci/messages/pull-request/18#comment-0, the value of "artifact.id" could be some sort of "composed" key, consisting of a repository and a digest? Or would be a digest alone unique enough, can one digest appear in different repositories?

Hi,
The idea is that the container-image artifact type represents a generic purpose container image which is built primarily outside of OSBS (OSBS built images have their own artifact type). The image is designed to be referenced using digests, like fedora@sha256:67dad89757a55bfdfabec8abd0e22f8c7c12a1856514726470228063ed86593b.
artifact.id seems invalid to me in this situation.

Personally I would prefer not to consuming an unknown artifact type.

If you need artifact.id to point to a value that uniquely identifies the artifact, the image digest alone is a good and valid candidate IMO. In this example, it would be just sha256:67dad89757a55bfdfabec8abd0e22f8c7c12a1856514726470228063ed86593b. Since schema 2 this digest is stable and should have the same value across different repositories and/or registries (assuming, of course, the registry supports schema 2).

You may want to include fedora@ as a way to also indicate the repository in which the image resides in the registry. Although, that is not part of the image identifier.

I do think it would be nice to have more consistency between the different artifact types.

I don't really care about the actual value of artifact.id, since - as has been pointed out to me thoughtfully - I am not (at this moment) consuming these messages; using the image digest was my first candidate.

What I've been proposing is the consistency - no matter what artifact a message describes, one can always find artifact's type in artifact.id, and artifacts unique ID among those of the same type in artifact.id.

Personally I find the practice of ad hoc exceptions, violating consistency of the whole idea being quite the opposite of "unification".

@rayson I personally like

fedora@sha256:67dad89757a55bfdfabec8abd0e22f8c7c12a1856514726470228063ed86593b

Can we go forward for this before this starts to get used?

Thanks!

@mvadkert @lucarval @happz
I am OK with using the digest as the artifact.id if the format of this field doesn't break anything.
I will follow up by updating the definition of container-image artifact type.

@rayson thanks, sounds good :)

@mvadkert @lucarval @happz
I am OK with using the digest as the artifact.id if the format of this field doesn't break anything.
I will follow up by updating the definition of container-image artifact type.

Thank you! I appreciate it, I think it will simplify things and help to keep the messages consistent across different artifacts.

https://pagure.io/fedora-ci/messages/pull-request/35 fixes this issue.

This issue has been fixed. CLosing