Strong type libartifact #522
Conversation
|
it should be noted that in addition to what my commit comments are, this will replace #463 ... but only a portion of it. i will address the broader issues in subsequent prs. |
|
✅ A new PR has been created in buildah to vendor these changes: containers/buildah#6565 |
| @@ -1,36 +1 @@ | |||
| github.com/BurntSushi/toml v1.4.0/go.mod h1:ukJfTF/6rtPPRCnwkur4qwRxa8vTRFBF0uk2lLoLwho= | |||
There was a problem hiding this comment.
This looks drastic (and potentially affects our ability to detect malicious tag changes) — if tools were complaining, go work sync && go work vendor might be sufficient.
There was a problem hiding this comment.
I’m not sure what is going on here — this PR is not changing dependencies, is it? Try just dropping this file out of the commit, perhaps.
| } | ||
|
|
||
| func getArtifactAndImageSource(ctx context.Context, as ArtifactStore, nameOrDigest string, options *libartTypes.FilterBlobOptions) (*libartifact.Artifact, types.ImageSource, error) { | ||
| func getArtifactAndImageSource(ctx context.Context, as ArtifactStore, asr ArtifactStoreReference, options *libartTypes.FilterBlobOptions) (*libartifact.Artifact, types.ImageSource, error) { |
There was a problem hiding this comment.
This should probably document that the store must be locked…
|
Given the API change, do we need a Podman PR lined up before merging this, to minimize drift/breakage? |
Yup!. I have a working branch that will just need a little TLC with the recent changes. Ill probably have done so by the time this merges. |
|
I think I have address all the review comments that are non-locking based, reserving those for later. |
mtrmac
left a comment
mtrmac
left a comment
There was a problem hiding this comment.
I’d think the change from .String() to .Name() in lookup code would break everything — am I missing something?
| @@ -1,36 +1 @@ | |||
| github.com/BurntSushi/toml v1.4.0/go.mod h1:ukJfTF/6rtPPRCnwkur4qwRxa8vTRFBF0uk2lLoLwho= | |||
There was a problem hiding this comment.
I’m not sure what is going on here — this PR is not changing dependencies, is it? Try just dropping this file out of the commit, perhaps.
Created two new types ArtifactReference and ArtifactStorageReference and switch the relevant exported functions to use these types. ArtifactReference is a theoretical reference to an artifact. It is essentially a named. As such, anything a named can be, so can this. This type is used in functions like pull and add. ArtifactStorageReference is also a theoretical reference to an artifact but to an artifact in the local store. The input to this type can be similar to an ArtifactReference. But it can also be a full or partial digest (sometimes called an ID) of the artifact in the store. It is used in functions like inspect and remove. GetByNameOrDigest was removed we now lookup artifacts using an unexported function (for now) as an object of the store. In my previous PR, issues outside the scope of typing were pointed out and while they are valid, I would like to address these issues in separate PRs. This PR does not address: * any locking issues that exist in artifacts * tests for the store or primary artifact functions Signed-off-by: Brent Baude <bbaude@redhat.com>
mtrmac
left a comment
mtrmac
left a comment
There was a problem hiding this comment.
LGTM if tests (and Podman tests against this) pass.
Thanks!
|
… OK still that unexpected |
|
/lgtm |
|
Oh, that's right, we have no mergebot. |
|
Where is the ready to go podman PR for this? I don't even see the test PR on the podman side. Folks, can we please stop merging breaking changes like this if the other side is not ready as well. Because now we block other people from doing the normal vendoring due the breaking changes. |
5 participants
Created two new types ArtifactReference and ArtifactStorageReference and switch the relevant exported functions to use these types.
ArtifactReference is a theoretical reference to an artifact. It is essentially a named. As such, anything a named can be, so can this. This type is used in functions like pull and add.
ArtifactStorageReference is also a theoretical reference to an artifact but to an artifact in the local store. The input to this type can be similar to an ArtifactReference. But it can also be a full or partial digest (sometimes called an ID) of the artifact in the store. It is used in functions like inspect and remove.
GetByNameOrDigest was removed we now lookup artifacts using an unexported function (for now) as an object of the store.
In my previous PR, issues outside the scope of typing were pointed out and while they are valid, I would like to address these issues in separate PRs. This PR does not address: