-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: Add standard SOURCE_TITLE metadata key #1296
Conversation
Depends: ostreedev/ostree#1296 As I mention in the commit there, I see two uses for this in rpm-ostree; first in our test suite, and second for OCI-built image imports. I also took a step further here and inject an `original-origin` metadata key, though we aren't actually using that yet. The problem I'm trying to solve there is that repeated `make vmoverlay` starts chaining things up, but that gets very confusing. I think we should always have `vmoverlay` unwind back to the base ref. (Or at least do that by default)
rpm-ostree consumption patch: coreos/rpm-ostree#1069 |
This is a cool idea! Should we also add a related |
I'm not sure...for the OCI case the checksum means a different thing than ostree. For I think my high level feeling here is - let's let the relevant tools add whatever metadata keys are specific to what they're doing, and if there's something to standardize down the line, we circle back here and do that? |
But hold off on merging, I'm going to update this PR to also render in |
21c6f2b
to
f556bcf
Compare
No functional changes; prep for more work.
Pull out the commit metadata explicitly; still just rendering the version, but this is prep for rendering other metadata keys.
This is a freeform string useful to track/display when a commit is "derived" from some other format. For example, in the rpm-ostree test we make a `vmcheck` ref that conceptually overlays the default ref like `fedora-atomic:fedora/26/x86_64/atomic-host`. My current patch sets the source title to e.g. "Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host". Another case I'm working on now is importing OCI images to use as host images. For that case, the source title is With this patch we could then set the original OCI image name + tag as the source name, like: "oci:cgwalters/demo-custom-fedora-atomic-host:26".
f556bcf
to
0633aa7
Compare
OK, rebased 🏄 and updated with some prep commits and adds testing. Lifting WIP. |
Looks good! Though the tests are complaining it seems. |
Whee, that was fun. Provoked a uboot integration bug. Fixup ⬆️ |
Pull out the commit metadata explicitly; still just rendering the version, but this is prep for rendering other metadata keys. Closes: #1296 Approved by: jlebon
This is a freeform string useful to track/display when a commit is "derived" from some other format. For example, in the rpm-ostree test we make a `vmcheck` ref that conceptually overlays the default ref like `fedora-atomic:fedora/26/x86_64/atomic-host`. My current patch sets the source title to e.g. "Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host". Another case I'm working on now is importing OCI images to use as host images. For that case, the source title is With this patch we could then set the original OCI image name + tag as the source name, like: "oci:cgwalters/demo-custom-fedora-atomic-host:26". Closes: #1296 Approved by: jlebon
☀️ Test successful - status-atomicjenkins |
Depends: ostreedev/ostree#1296 As I mention in the commit there, I see two uses for this in rpm-ostree; first in our test suite, and second for OCI-built image imports. I also took a step further here and inject an `original-origin` metadata key, though we aren't actually using that yet. The problem I'm trying to solve there is that repeated `make vmoverlay` starts chaining things up, but that gets very confusing. I think we should always have `vmoverlay` unwind back to the base ref. (Or at least do that by default)
Depends: ostreedev/ostree#1296 As I mention in the commit there, I see two uses for this in rpm-ostree; first in our test suite, and second for OCI-built image imports. I also took a step further here and inject an `original-origin` metadata key, though we aren't actually using that yet. The problem I'm trying to solve there is that repeated `make vmoverlay` starts chaining things up, but that gets very confusing. I think we should always have `vmoverlay` unwind back to the base ref. (Or at least do that by default)
Depends: ostreedev/ostree#1296 As I mention in the commit there, I see two uses for this in rpm-ostree; first in our test suite, and second for OCI-built image imports. I also took a step further here and inject an `original-origin` metadata key, though we aren't actually using that yet. The problem I'm trying to solve there is that repeated `make vmoverlay` starts chaining things up, but that gets very confusing. I think we should always have `vmoverlay` unwind back to the base ref. (Or at least do that by default) Closes: #1069 Approved by: jlebon
This is a freeform string useful to track/display when a commit is "derived"
from some other format. For example, in the rpm-ostree test we make a
vmcheck
ref that conceptually overlays the default ref likefedora-atomic:fedora/26/x86_64/atomic-host
.My current patch sets the source title to e.g.
"Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host".
Another case I'm working on now is importing OCI images to use
as host images. For that case, the source title is
With this patch we could then set the original OCI image name + tag
as the source name, like:
"oci:cgwalters/demo-custom-fedora-atomic-host:26".