Skip to content
This repository has been archived by the owner on Jan 20, 2025. It is now read-only.

Feature/heredocs #202

Merged

Conversation

sebastian-echeverria
Copy link
Contributor

Added support for properly parsing heredocs in dockerfiles. Addresses #174 .

  • Updated buildkit version to minimum version to support heredocs
  • Added functionality to go parser to properly parse Value and Original fields for heredocs.
  • Added go and docker tests for heredocs

parse_test.go Outdated Show resolved Hide resolved
parse_test.go Outdated Show resolved Hide resolved
parse.go Show resolved Hide resolved
parse_test.go Outdated
StartLine: 1,
EndLine: 5,
Flags: []string{},
Value: []string{"content 1\n", "content 2\n"},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where did /dest go? this doesn't seem right

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree, but unfortunately that is how buildkit is parsing that case. If you look at the sample test case they have at https://github.com/moby/buildkit/blob/master/frontend/dockerfile/parser/parser_heredoc_test.go line 67, then the expected value at 204, the /dest does disappear. I am not sure why they are doing this, but since we are not trying to improve on their parser but just support what they do, this is the way our test case is behaving as well. At most, we could think about putting it in some manner in the Value field, which I was kinda doing before, but changes in the heredoc substructure should depend on changes they make.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the whole point of this is to allow one to get the whole structural syntax by improving on the parser

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. The whole point is to bring parity with the current version of the docker parser in buildkit, which has heredocs support. Since this library is just a wrapper around that, the best we can do is to wrap around what that parser is doing. If that parser has bugs or shortcomings, the proper place to fix it is over there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That being said, I realized that the contents of the Value field now for the heredocs do not make much sense, given the new Heredocs structure and the fact that the Heredocs contents are now in there. I pushed a new change where I modified the Value field to go back to how it works for all command, which for the Heredocs case means that it will parse the first line of the command, including the names of the heredocs and anything else in that line, like the "/dest" param in that line. The Heredocs substructure will work as the attachment with the contents of the heredocs, which is how buildkit does it and how it is probably used.

),
dockerfile.Command(
cmd='CMD', sub_cmd=None, json=True, value=('echo', '☃'),
start_line=2, end_line=2, original='CMD ["echo", "☃"]', flags=(),
heredocs=(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this indicates an api breaking change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, but this is due to the api breaking change buildkit did by adding the new herdocs structure, so we are consistent with their changes. If there is a way to pass a default value to the go-to-python constructor for the Command, I could do that to avoid this external change, but I have not looked into that yet. If you feel this is important, I can try to add a default empty value. However, the current behavior is consistent with, for example, the flags argument, which is provided an empty value when no flags are used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't have pointed it out if I didn't want you to fix it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, which is why I replied by pointing out the pros and cons. Pushed a new version that avoids breaking the API.

pylib/main.go Outdated

pyFileDescriptor := C.PyLong_FromLong(C.long(heredoc.FileDescriptor))

pyContent := stringToPyOrNone(heredoc.Content)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be OrNone ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

pylib/main.go Outdated
Comment on lines 127 to 128
C.Py_DecRef(ret)

}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please review your PR and remove any unnecessary changes like this one (there are several)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cleaned up a couple of lines like this one

pylib/support.c Outdated
Comment on lines 73 to 75
PyObject* defaults = PyTuple_New(1);
PyObject* default_heredoc = PyTuple_New(0);
PyTuple_SetItem(defaults, 0, default_heredoc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty sure this can be done simpler with BuildValue ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@asottile asottile merged commit 68c6f9d into asottile-archive:main Jan 4, 2025
12 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants