-
Notifications
You must be signed in to change notification settings - Fork 152
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
Add history metadata for container builds #871
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a typo.
Looks good from the XML, but I wonder whether it makes sense to allow specifying multiple history entries - I think kiwi does everything in one transaction.
I'm not opposed to it though, it might even be useful in the future.
Can you build kiwi with this PR on OBS so that I can have a try?
97ea9e3
to
9bf38b7
Compare
@schaefi, @Vogtinator while implementing it I noticed we should agree on the behavior of the history records. With the current implementation a <type image="docker">
<containerconfig
name="opensuse"
tag="tumbleweed"
maintainer="David Cassany <dcassany@suse.com>">
<history author="David" created_by="A kiwi build">This is some comment for history</history>
</containerconfig>
</type> Produces a
I noticed that each
With the suggested implementation
The last My doubts here are related to default values and what happens if multiple Regarding default values:
I am not a fan of those options, but would make the description file less verbose and also fill history records with the user provided data. Regarding multiple
All those options have very little impact on the current suggested implementation, so I am opened to agree on a different behavior. |
Isn't it possible to just use a single umoci call for everything? |
No, at least In any case we need to agree about the expectations for history records using current umoci. |
I think a good solution would be the ability to have a --no-history flag for umoci repack/config commands. I think that's what @cyphar suggested to add. However the current umoci doesn't provide this feature. Given it can be added I vote for that solution plus an updated version check in the check_docker_tool_chain_installed() runtime check. Having a history entry for the umoci repack looks weird to me as we need that to process the initial creation of the container archive only. If we have to add a comment it imho should express something like That information wouldn't be that meaningful and I think if the container is used as a base container all that history entries gets inherited which creates a weird history. So my first vote would be to have an option to skip the history entry such that we can create an image which only provides meaningful history entries Thoughts ? |
|
Yup.
As long as there's a fallback to having a mostly useless entry in case umoci doesn't support the option, I agree. |
The patch for
This is a peculiarity of OCI images. In order for other tools to understand your image history, you have to have an image history associated with each layer (it's really ugly how it works internally, it's just a dumb list with a boolean saying whether a particular entry is associated with a layer or not -- so layers without history entries break the history entries of later layers). In theory you could order them in any order you like, but obviously we'd need to have a UX to do this and thus another |
I agree, having the repack last would be a good call order change |
great you are fast :) So once merged this results in a package build somewhere ? |
No, but I can do a release and so on quite fast. There is a bug in tests, I will fix it up. :P |
Given the discussion and @cyphar collaboration I suggest the following approach. 1- Make a new PR with a little refactor on how we call I think this should be simple and safe. @Vogtinator, @schaefi does it make sense to you? |
Yup. I'm not sure why step 1 is necessary though. |
not necessary but desirable I'd say. Also for dervied images we have one extra |
workflow sounds good to me, I think we don't need a new PR and just update this one here |
f067549
to
769b97e
Compare
@schaefi, finally I have not reordered our So now with a type section like: <type image="docker">
<containerconfig name="opensuse" tag="tumbleweed">
<history>Include tumbleweed base image layer</history>
</containerconfig>
</type> we get a history record like:
And for derived images, with type section like: <type image="docker" derived_from="file:///mybaseimage.tar">
<containerconfig name="opensuse/derived" tag="derived">
<history author="David" created_by="A kiwi build">Adding a new layer</history>
</containerconfig>
</type> we get a history record like:
This will be the result of any build using an I'll make the implementation of |
This commit adds the history section in contianerconfig. With it 'author', 'created_by' and 'comment' can be customized. In addition 'created' is always included with the image creation date time. 'created_by' entry is set to 'KIWI __version__' by default if nothing is provided. Fixes #852
769b97e
to
f061248
Compare
Yes, this is the case. It's actually not that the configuration is being restored, it's that
Are you sure that output is right? Why is a config change being listed as being |
Yes I understand, anyway this is not an issue.
It is right, at least the copy & paste I did :)
This is the command sequence:
I have no checked the history records for the OCI image neither the history records before being loaded, thus I guess it could be also |
}) | ||
'entry_subcommand': ['/bin/bash'], | ||
'history': {'created_by': 'KIWI {0}'.format(__version__)} | ||
}, True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had added the base_image
as real Boolean because this test was really confusing if not. I know the result is the same, but having a string pointing to a directory here felt really strange.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes understood, actually I also liked what @cyphar suggested
bool(base_image)
This commit adds the history section in contianerconfig. With it
'author', 'created_by' and 'comment' can be customized. In addition
'created' is always included with the image creation date time.
'created_by' entry is set to 'KIWI version' by default if nothing
is provided.
Fixes #852