Draft
Conversation
|
Ephemeral COPR build failed. @containers/packit-build please check. |
4 similar comments
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Ephemeral COPR build failed. @containers/packit-build please check. |
929d193 to
fa4f264
Compare
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It's surprising to have it in a package that otherwise contains almost exclusively type definitions, and we are breaking the API either way. Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
I can't see much of a benefit to abstracting this; if anything, using named struct fields instead of unnamed parameters increases clarity and decreases the risk of a mismatch. Intentionally a minimal refactor, leaving the sourceCtx/destinationCtx variables. That will be cleaned up momentarily. Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It _probably_ does not matter, src should read from c/storage, but there's a few layers of abstraction and there is BlobCache, so fill it to be safe. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... when trying to add an unknown-arch list item Maybe this should just strip specifically the architecture options, instead. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Probably makes no difference, but it's easier to do it than worry. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This does not do anything without declaring the option first. That will come momentarily. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
What this PR does / why we need it:
Add
--tls-detailsoptions to many CLI operations, exposing containers/container-libs#623 . Hopefully this will also be sufficient for integration into Podman, confirmation of that TBD.How to verify it
TBD. This should have at least some smoke tests
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
I’m fairly unsatisfied with the CLI top level:
--tls-detailsoption wherever there is aSystemContext. Some of that is almost certainly unnecessary (buildah tag), but I wanted to avoid surprises likebuildah manifest inspect. I’m not sure how else to make this maintainable over a longer term, ensuring that contributors of new features don’t forget to add the--tls-detailsoption.parse.SystemContextFromOptionssilently ignores undeclared options, and requires the CLI layer to individually declare each new option, makes for a finely tuned CLI options sets but it’s fairly hard to track or ensure consistency. (I have no ambition of significantly restructuring that in this PR.)Does this PR introduce a user-facing change?