You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(1) Avoids unexpected behavior when a new image has been published to a given tag after analyzer has run, but before exporter has completed. Currently a buildpack may indicate (by leaving a layer.toml file with no corresponding directory) that it wishes to reuse a layer. However, if that layer changes due to this race condition, the layer that is reused might be different than the layer validated by the buildpack
(2) Provides an easy way to publish the same image to multiple tags (e.g. an immutable rc-17 tag and a mutable :latest tag). This is important for auditability and rollbacks when using registries like artifactory that garbage collect untagged images.
(3) Explicitly disentangles two concepts which the current lifecycle API blurs together. The previous (analyzed) image and the desired export tag.
analyzer
When I run analyzer registry.com/some/image:tag -analyzed /path/to/analyzed.toml Thenanalyzer, in additional to the current behavior, writes a analyzed.toml file to the given path with the following information
When I run exporter some/image:tag some/other:tag -analyzed /path/to/analyzed.toml Then the exporter will fetch reused layers from registry.com/some/image@<image-digest> And the exporter will export to all tags provided
Flag details
-analyzed will be an optional flag on both analyzer and exporter and will default to ./analyzed.toml
Backwards compatibility
If exporter cannot find the analyzed.toml file it will fails (this means that a previous version on the analyzer binary cannot be used with the newest version of the exporter binary, which seems like an acceptable limitation).
The text was updated successfully, but these errors were encountered:
After a discussion with @ekcasey, we want to enforce that the run image used for each provided image tag uses the same registry as that image tag to preserve locality during export.
* Export to multiple tags
* Use analyzed.toml in exporter
[#138]
Signed-off-by: Javier Romero <jromero@pivotal.io>
Signed-off-by: Danny Joyce <djoyce@pivotal.io>
When analyzer is run with the -daemon flag the reference that is stored in the analyzed.toml file is the image ID. In the future we would like to write this value in the daemon case to a key named image-id for naming accuracy and clarity.
Motivations:
This issue accomplishes three goals.
(1) Avoids unexpected behavior when a new image has been published to a given tag after
analyzer
has run, but beforeexporter
has completed. Currently a buildpack may indicate (by leaving alayer.toml
file with no corresponding directory) that it wishes to reuse a layer. However, if that layer changes due to this race condition, the layer that is reused might be different than the layer validated by the buildpack(2) Provides an easy way to publish the same image to multiple tags (e.g. an immutable
rc-17
tag and a mutable:latest
tag). This is important for auditability and rollbacks when using registries like artifactory that garbage collect untagged images.(3) Explicitly disentangles two concepts which the current lifecycle API blurs together. The previous (analyzed) image and the desired export tag.
analyzer
When I run
analyzer registry.com/some/image:tag -analyzed /path/to/analyzed.toml
Then
analyzer
, in additional to the current behavior, writes aanalyzed.toml
file to the given path with the following informationexporter
Given I have a file at path
/path/to/analyzed.toml
with the following contentsWhen I run
exporter some/image:tag some/other:tag -analyzed /path/to/analyzed.toml
Then the
exporter
will fetch reused layers fromregistry.com/some/image@<image-digest>
And the
exporter
will export to all tags providedFlag details
-analyzed
will be an optional flag on bothanalyzer
andexporter
and will default to./analyzed.toml
Backwards compatibility
If exporter cannot find the
analyzed.toml
file it will fails (this means that a previous version on theanalyzer
binary cannot be used with the newest version of theexporter
binary, which seems like an acceptable limitation).The text was updated successfully, but these errors were encountered: