Skip to content
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 core 'ports' functionality to docker context exporter, fix cross-platform Dockerfile write inconsistency #438

Merged
merged 36 commits into from
Jun 25, 2018

Conversation

TadCordle
Copy link
Contributor

@TadCordle TadCordle commented Jun 22, 2018

After merging #432. Part of #383.

@TadCordle TadCordle changed the title Port docker context Add core 'ports' functionality to docker context exporter Jun 22, 2018
@@ -193,4 +206,19 @@ static String joinAsJsonArray(List<String> items) {

return resultString.toString();
}

/**
* Builds a list of Dockerfile "EXPOSE" items.
Copy link
Contributor

Choose a reason for hiding this comment

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

In Dockerfile terminology, they are called "instructions".

static String makeExposeItems(List<String> exposedPorts) {
StringBuilder resultString = new StringBuilder();
for (String port : exposedPorts) {
resultString.append("EXPOSE ").append(port).append("\n");
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: can be '\n'

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, if you don't want the extra new line at the end of the list, you can do a join instead.

* @return a string containing an EXPOSE command for each of the entries
*/
@VisibleForTesting
static String makeExposeItems(List<String> exposedPorts) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like I messed up the ordering for joinAsJsonArray as well, but these static methods should be moved up top.

@@ -4,5 +4,5 @@ COPY libs @@DEPENDENCIES_PATH_ON_IMAGE@@
COPY resources @@RESOURCES_PATH_ON_IMAGE@@
COPY classes @@CLASSES_PATH_ON_IMAGE@@

ENTRYPOINT @@ENTRYPOINT@@
@@EXPOSED_PORTS@@ENTRYPOINT @@ENTRYPOINT@@
Copy link
Contributor

Choose a reason for hiding this comment

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

Should leave some new lines in between

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 did that so there are no stray newlines when it gets replaced.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea, the stray newlines should be an implementation fix rather than on the template itself or it decreases the readability of the template.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, a nit, but perhaps EXPOSE_INSTRUCTIONS is a more applicable naming of the template section?

@@ -4,5 +4,7 @@ COPY libs /app/libs/
COPY resources /app/resources/
COPY classes /app/classes/

EXPOSE 1000
EXPOSE 2000-2010
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a valid instruction? If not, we might want to reconsider supporting this type of syntax in our configuration, and try to keep it as similar to Dockerfile EXPOSE as possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes

Copy link
Contributor

Choose a reason for hiding this comment

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

Cools

Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about supporting UDP?

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 sounds like a useful thing and probably wouldn't be too hard to add.

@VisibleForTesting
static String joinAsJsonArray(List<String> items) {
StringBuilder resultString = new StringBuilder("[");
boolean firstComponent = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

Doing a join would avoid this first logic:

String.join("\n", exposedPorts.stream().map(port -> "EXPOSE " + port).collect(Collectors.toList()));

coollog
coollog previously approved these changes Jun 22, 2018
@TadCordle TadCordle dismissed coollog’s stale review June 22, 2018 20:56

Needed to fix platform specific file stuff, would like a re-review please

@@ -84,7 +84,8 @@ static String joinAsJsonArray(List<String> items) {
@VisibleForTesting
static String makeExposeItems(List<String> exposedPorts) {
return String.join(
"\n", exposedPorts.stream().map(port -> "EXPOSE " + port).collect(Collectors.toList()));
System.getProperty("line.separator"),
Copy link
Contributor

Choose a reason for hiding this comment

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

That's interesting. I'm wondering why this would need this platform-specific separator when the template's lines are separated by just LF?

Also, was the error with Docker not accepting non CRLF on windows?

Copy link
Contributor Author

@TadCordle TadCordle Jun 22, 2018

Choose a reason for hiding this comment

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

I didn't look that deeply into it. The error was from the DockerContextGenerator unit test and said that the sample and the generated docker file lengths differed by 1 on windows, so I assumed it was using "\r\n" as separators and was missing a "\r".

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm that might mean the test should be fixed. I think the docker context generated should be platform independent so that a user generating on linux or windows would produce the same context for the same project.

Copy link
Contributor

@coollog coollog left a comment

Choose a reason for hiding this comment

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

I think we should still figure out why it was not working with the resource file though.

* @return a string containing an EXPOSE instruction for each of the entries
*/
@VisibleForTesting
static String makeExposeItems(List<String> exposedPorts) {
Copy link
Contributor

Choose a reason for hiding this comment

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

makeExposeInstructions?

@@ -47,6 +46,18 @@
*/
public class DockerContextGenerator {

/** The template to generate the Dockerfile from. */
private static final String DOCKERFILE_TEMPLATE =
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're changing to just building the string in the code, we can just use stringbuilder and append the parts rather than doing the template replacement.

@TadCordle
Copy link
Contributor Author

TadCordle commented Jun 25, 2018

I think we should still figure out why it was not working with the resource file though.

Yeah I'm just trying things right now.

@TadCordle
Copy link
Contributor Author

@coollog @loosebazooka I think this is review-able, finally.

I got it working with the DockerfileTemplate in this commit, but ended up removing it anyway for efficiency.

@TadCordle TadCordle changed the title Add core 'ports' functionality to docker context exporter Add core 'ports' functionality to docker context exporter, fix cross-platform Dockerfile write inconsistency Jun 25, 2018
*/
@VisibleForTesting
static String joinAsJsonArray(List<String> items) {
return "["
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh for this we could actually use ObjectMapper from the JSON library we use (I forgot about it when implementing this). It will automatically generate the JSON string from a list of strings.

You could do like

Blobs.writeToString(JsonTemplateMapper.toBlob(thelist))

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 think it needs a ListOfJsonTemplate, not a list of strings?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh right, maybe just use new ObjectMapper().writeValueAsString directly.


/**
* Formats a list for the Dockerfile's ENTRYPOINT or CMD.
* Makes the contents of a {@code Dockerfile} using configuration data.
Copy link
Contributor

Choose a reason for hiding this comment

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

Since we're putting this in code, would be good to have in the javadoc an example of what it would look like.

+ sourceFilesConfiguration.getResourcesPathOnImage()
+ "\nCOPY classes "
+ sourceFilesConfiguration.getClassesPathOnImage()
+ "\n\n"
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh wait, wouldn't this add 3 newlines if there weren't any exposed ports?

* @return a string containing an EXPOSE instruction for each of the entries
*/
@VisibleForTesting
static String makeExposeInstructions(List<String> exposedPorts) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This could also be moved to makeDockerfile and change that to append to a StringBuilder as an alternative.

@TadCordle TadCordle merged commit 149bfeb into master Jun 25, 2018
@TadCordle TadCordle deleted the port_docker_context branch June 25, 2018 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants