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 container.appRoot config parameter #984

Merged
merged 33 commits into from
Sep 19, 2018
Merged

Conversation

chanseokoh
Copy link
Member

@chanseokoh chanseokoh commented Sep 13, 2018

Fixes #964

@@ -32,6 +32,12 @@
/** The default creation time of the container (constant to ensure reproducibility by default). */
public static final Instant DEFAULT_CREATION_TIME = Instant.EPOCH;

/**
* The default app root in the image. For example, if this is set to {@code "/helloworld-app"},
Copy link
Member

@loosebazooka loosebazooka Sep 13, 2018

Choose a reason for hiding this comment

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

I feel like the example should just use the current default value? #976

@@ -131,6 +131,11 @@ private static String mapToDockerfileString(Map<String, String> map, String comm
return joiner.toString();
}

@VisibleForTesting
static String getUnixPath(Path path) {
Copy link
Member

Choose a reason for hiding this comment

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

I think another PR has a similar utility, might be worth using the same for both?

Copy link
Member Author

Choose a reason for hiding this comment

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

Certainly. Since that utility is not yet available, I'll add a TODO here to use the utility.

}

/** Builds with each layer's files. */
public static class Builder {

private final Map<LayerType, List<Path>> layerFilesMap = new EnumMap<>(LayerType.class);
private Path appRoot = Paths.get(ContainerConfiguration.DEFAULT_APP_ROOT);
Copy link
Member

Choose a reason for hiding this comment

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

I'm worried path might be implementation specific (different on windows), and this should be a string? Specifically when running Jib on a windows machine.

Copy link
Member Author

Choose a reason for hiding this comment

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

I had the same concern intially, but since the existing code is actually using Path to pass to addEntryRecursively(), I think it seemed better to accept Path for now: https://github.com/GoogleContainerTools/jib/pull/984/files#diff-1105d9e04ba077f47449d5c7095d4252L123 Maybe addEntryRecursively() shouldn't accept Path.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, your suggestion seems better. I changed it to accept Unix-style path in String instead of Path. This also removes the need for the toUnixPath() helper.

Copy link
Member

Choose a reason for hiding this comment

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

Looks like addEntryRecursively actually boils down to some Unix path conversion eventually.

public String getAbsoluteExtractionPathString() {

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, so I'm wondering all the methods and classes that need the extraction path info should get the path in String rather than Path to indicate clearly that the extraction path is and will end up in Unix-style.

@@ -110,6 +125,8 @@ public Builder setExplodedWarFiles(List<Path> explodedWarFiles) {
}

public JavaLayerConfigurations build() throws IOException {
Preconditions.checkState(appRoot.isAbsolute(), "'appRoot' must be an absolute path");
Copy link
Member

Choose a reason for hiding this comment

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

this seems like we might need to use a custom validator that is not OS specific.

Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure I get what you mean. (Is C:\dir not absolute, for example? Even so, I think it is right to fail, since we assume we build a Linux image.)

Anyways, I think we have been assuming that this appRoot should always in Unix-style in the end.

Copy link
Member Author

Choose a reason for hiding this comment

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

Whatever you meant, I think this will be taken care of properly after I appRoot from Path to String. The new condition will look like

      // Windows filenames cannot have "/", so this also blocks Windows-style path.
      Preconditions.checkState(appRoot.startsWith("/"),
          "appRoot should be an absolute path in Unix-style");

@loosebazooka
Copy link
Member

oops sorry I jumped the gun on the review there a little. Didn't see the NOT READY label.

@chanseokoh
Copy link
Member Author

Ready for review.

You might first think too many files were touched, but the actual code change to make this work isn't really that large, when excluding tests.

@chanseokoh chanseokoh requested a review from a team September 17, 2018 17:50
@@ -36,47 +36,62 @@
/** Represents the different types of layers for a Java application. */
@VisibleForTesting
enum LayerType {
DEPENDENCIES("dependencies", JavaEntrypointConstructor.DEFAULT_DEPENDENCIES_PATH_ON_IMAGE),
DEPENDENCIES(
Copy link
Member Author

Choose a reason for hiding this comment

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

Thinking more about this enum where we need to dynamically decide the final extraction path, I'm now leaning toward getting rid of static extraction path initialization with the appRootRelative switch. Instead, the JavaLayerConfiguration.Builder() could accept the extraction path when setting layer files. That is, change setClassFiles(List<Path> classFiles) to setClassFiles(String extractionPath, List<Path> classFiles). That seems more straightforward for our dynamic path requirement and simpler. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea that sounds good. One nit is to have it be setClassFiles(List<Path> classFiles, String extractionPath) to be more like LayerEntry.

@chanseokoh
Copy link
Member Author

Will re-design this per #984 (comment). Not ready for review until then.

@chanseokoh
Copy link
Member Author

Ready for review

@@ -134,10 +146,13 @@ public static Builder builder() {
}

private final ImmutableMap<LayerType, LayerConfiguration> layerConfigurationMap;
private final ImmutableMap<LayerType, String> defaultExtractionPathMap;
Copy link
Contributor

Choose a reason for hiding this comment

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

Just extractionPathMap? This doesn't look like it's getting any defaults.

this.layerConfigurationMap = layerConfigurationsMap;
ImmutableMap<LayerType, LayerConfiguration> layerConfigurationsMap,
ImmutableMap<LayerType, String> defaultExtractionPathMap) {
layerConfigurationMap = layerConfigurationsMap;
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should name these both layerConfigurationsMap so this can be the more familiar this.x = x form?

@@ -170,7 +185,35 @@ private JavaLayerConfigurations(
return getLayerEntries(LayerType.EXPLODED_WAR);
}

public String getDependencyDefaultExtractionPath() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are these getting defaults or the actual extraction path?

Copy link
Member Author

@chanseokoh chanseokoh Sep 18, 2018

Choose a reason for hiding this comment

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

I'll drop Default from the name.


private Builder() {
for (LayerType layerType : LayerType.values()) {
layerFilesMap.put(layerType, new ArrayList<>());
extractionPathMap.put(layerType, "/");
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a need to initialize these with the path as "/"? (Perhaps the code that builds the LayerConfiguration can skip if the files or extraction path is empty?)

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it's good to have "/". Otherwise, we may go into the business of returning Optional<String> for getResourceExtractionPath() instead of String.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, since these get...ExtractionPath methods are really only used for Docker context generation (via addIfNotEmpty) and since this default / is not actually used when the layer entries is empty, perhaps we would need to actually reorganize the API of JavaLayerConfigurations, but this can be a separate issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good idea. I was thinking the same. I'll file an issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

Filed #1010.

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.

Are you planning to merge the Absolute/RelativeUnixPath changes in this PR or first merge this PR?


private Builder() {
for (LayerType layerType : LayerType.values()) {
layerFilesMap.put(layerType, new ArrayList<>());
extractionPathMap.put(layerType, "/");
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, since these get...ExtractionPath methods are really only used for Docker context generation (via addIfNotEmpty) and since this default / is not actually used when the layer entries is empty, perhaps we would need to actually reorganize the API of JavaLayerConfigurations, but this can be a separate issue.

@chanseokoh
Copy link
Member Author

chanseokoh commented Sep 19, 2018

Are you planning to merge the Absolute/RelativeUnixPath changes in this PR or first merge this PR?

I was about to do this. If you think you can approve this PR soon, let's merge it, and I'll work on AbsolutePath right away. Otherwise, I can work it in this PR.

@coollog
Copy link
Contributor

coollog commented Sep 19, 2018

Okay let's merge this first then so the changeset is smaller. I think we may possibly want to have #1009 fixed before changing this over.

@chanseokoh chanseokoh merged commit 34c4e49 into master Sep 19, 2018
@chanseokoh chanseokoh deleted the i964-container.appRoot branch September 19, 2018 19:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants