-
Notifications
You must be signed in to change notification settings - Fork 53
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
Adds tools for editing tags. #129
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
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.
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.
This change shouldn't be here
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.
The use case I have: I have a dockerfile with images & tags (that are not "latest" since we want to pin our images to specific tags).
Every once in a while I want to (semi-automatically) update these tags within the dockerfile. e.g.:
While dockerfile-parse has the tools to load the dockerfile and get the image it was lacking tools to split up this image in it's base components (
registry\image:tag
). Currently I'm using this in a seperate script but I doubt i'm the only person that would like to just update the tags of an image.My personal use case is heavily "tag" focussed. The way I see it
tag
is a seperate imput for theFROM
keyword (as per the docker documentationI think the first thing we'd need to agree apon is: "Is the tag part of the image name"?
If no: Then a seperate "ImageNameParser" is the better structure. (Would this be a seperate repo?).
If yes: Then I think this PR would be in the right direction.
Edit:
I was looking back at my other PR and remembered something:
Ideally I would change the entire "image_from" function to a "parse_FROM" function which returns all values that you could give the
FROM
keyword (platform, image, digest, tag and name). But that would have been massively breaking (since this entire project assumes "tag" is part of your image, and not a seperate entity). So I opted for this solution.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, dockerfile-parse works with imagename as a whole including digest or tag.
I'm not very eager to make it more granular, because we may also split imagename into: registry, namespace, image, tag/digest. There are multiple parts, many of them optional.
I'd like to keep dockerfile parse simple and rather use 3rd party library to manipulate with image string and just pass it to dockerfile parse
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.
We are using it like that, dockerfile just provides raw string, we manipulate it with separate code
https://github.com/containerbuildsystem/osbs-client/blob/master/osbs/utils/__init__.py#L372
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.
This is naming convention we use
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.
Is there a specific 3rd party "image parser" that you know of that works with this convention?
I find it odd that osbs-client (your link) contains the logic to split up the image into registry, tag, name etc. which seems to be a bit counterintuitive with the "keep responsibility seperated" mentality.
The thing that I apparently am running against is that this repo doesn't seem to be a generic "dockerfile parser" but an "osbs dockerfile parser" which decreases the usability of it somewhat.
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 don't follow what do you mean.
What I want to avoid, is having separate method for everything: get_tag, set_tag, get_registry, set_registry, etc..
We are modifying registry part, we didn't put that code into docker_file parse, because it's better to have single class for manipulating with imagenames and then just write back string representation into dockerfile parse.
This also work for all stages in Dockerfile, not just final stage.
What could be good, is to modify dockerfile-parse to return imagename as object where you can use methods to modify image, or make this more object oriented, and return object per stage.
I'd like to keep here some OOP decoupling between image and dockerfile statements
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 think I'm starting to get your intention.
But if you'd truly want to decouple dockerfile statements I would expect something like
get_FROM_arguments()
Which would return all the possible arguments that are allowed for theFROM
statement (see dockerfile reference). Or a class (FromArguments
) where you can set the different arguments.Regardless of the approach. What I don't really get is: Why isn't the
ImageName
class included in osbs-client? And not in dockerfile-parse? (or why isn't it a seperate repo?).The thing thats bugging the most in the current set-up is that being able to change just the tag (or just the registry or other seperate component of "image") seems to be a fairly common & normal use case. And to achieve that either needs you to add your own functions (which I am sharing here) or install osbs-client (which doesn't seem to be available via pip?). Which raises my earlier question: Is
dockerfile-parse
meant as just a supplementary tool for osbs-client or as a tool for anyone who want to parse dockerfiles (and nothing else).Edit:
Just spitballing:
Would it be more fitting for this project if the ImageName class from osbs-client was moved to util.py from this project?
Or these tag functions to util.py?
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.
Historical reasons, I don't know. Before it was part of atomic-reactor.
This would work for me, sounds like great idea. Let's wait what other maintainers things about it.
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.
moving ImageName here and returning base/parent images with it sounds good to me