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

Write out the image metadata to a file after build. #2227

Merged

Conversation

mbruggmann
Copy link
Contributor

@mbruggmann mbruggmann commented Jan 11, 2020

The jib-maven-plugin will now create a json file with image
metadata during the build, like so:

$ mvn jib:build
...
$ cat target/jib-image.json | jq .
{
  "image": "gcr.io/project/image:tag",
  "imageId": "sha256:61bb3ec31a47cb730eb58a38bbfa813761a51dca69d10e39c24c3d00a7b2c7a9",
  "imageDigest": "sha256:3f1be7e19129edb202c071a659a4db35280ab2bb1a16f223bfd5d1948657b6fc",
  "tags": ["latest", "tag"]
}

This is handy if you generate the image name or tag in a dynamic
fashion (eg, including a timstamp) and you have other tools in a
CD pipeline that operate on the generated image. In our case, we
would like to use the reference to the generated image to deploy to
K8S, and our deployment tooling picks it up from a file.

The path to the output file is configurable in
outputPaths.imageJson.

Related issue: #1875

If the maven plugin is configured with an `imageName` output
path:
```xml
<configuration>
  <to>
    <image>gcr.io/some/path/to/image:tag</image>
  </to>
  <outputPaths>
    <imageName>target/jib-image.name</imageName>
  </outputPaths>
</configuration>
```

The jib-maven-plugin will now create a file at that path with
the image name during the build, like so:
```
$ mvn jib:build
...
$ cat target/jib-image.name
gcr.io/some/path/to/image:tag
```

This is handy if you generate the image name or tag in a dynamic
fashion (eg, including a timstamp) and you have other tools in a
CD pipeline that operate on the generated image. In our case, we
would like to use the reference to the generated image to deploy to
K8S, and our deployment tooling picks it up from a file.

I have only implemented support in the maven plugin for now, since
that is what we are using and I'm not really familiar with Gradle.
That should be pretty straight-forward to add, if need be.

When it comes to the implementation, I imitated how the image id
and digests are written out for now. Changing to a json or yaml
output format felt like a bigger (breaking) change.

Related issue: GoogleContainerTools#1875
Copy link
Member

@loosebazooka loosebazooka left a comment

Choose a reason for hiding this comment

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

I'm not sure this is something we want to do. I see the usecase, but this can be solved in plugins already - you can write a custom gradle task to do this, or use something like the Maven ant-run plug-in. It just feels strange to write out an input directly without modifying it.

@mbruggmann
Copy link
Contributor Author

@loosebazooka Agree that there are workarounds using other maven/gradle plugins. Two things I'm wary about with that approach:

  • We need to force the plugins to run on the same lifecycle for it to make sense. Also, issuing mvn jib:build manually doesn't produce the image metadata file.
  • The image name is duplicated in the pom, once for the jib plugin and once for producing the file. This means that if a consumer of the parent pom overwrites the jib to.image, passes it in through the CLI, by setting a property etc the output won't match.

How about combining the repository, digests, tags etc into a single jib-image.json output file, as per linked issue? Would that make more sense? Otherwise I'm happy to close this and explore other solutions form our side of course.

@loosebazooka
Copy link
Member

@mbruggmann these are good points. I think we're still working out how we want jib-image.json to work, but this might be a good time to do it.
We will probably leave the other files for backwards compatibility.

@mbruggmann mbruggmann changed the title Optionally write out the image name to a file after build. Write out the image metadata to a file after build. Jan 14, 2020
@loosebazooka
Copy link
Member

@mbruggmann the changes look nice, I'll take a deeper look, can you also output the extra tags in the json file?

Copy link
Member

@briandealwis briandealwis left a comment

Choose a reason for hiding this comment

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

Looks good! Two little nits that I saw.

.thenReturn(mockJibContainer);
testJibBuildRunner.writeImageJson(outputPath).runBuild();

final String outputJson = new String(Files.readAllBytes(outputPath), StandardCharsets.UTF_8);
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 it would be better to compare this output explicitly as a string to ensure we're producing expected output. (For example, to detect a situation where we change JSON libraries that produces slightly-invalid JSON.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Had a look at this. Beyond putting the full expected json into a string in the testcase (which seems highly specific) I didn't find a good way of doing that.

As of now, the next line of ImageMetadataOutput.fromJson(outputJson) will at least make sure it properly parses into the expected type so it should catch any invalid JSON, serialization/deserialization differences and similar.

@mbruggmann
Copy link
Contributor Author

Added support for tags now if you'd like to take another look @loosebazooka @briandealwis

Copy link
Member

@briandealwis briandealwis left a comment

Choose a reason for hiding this comment

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

Looks good!

@loosebazooka
Copy link
Member

Probably kind of annyoing, given our integration tests only run on internal machines (and you can't see the output). But can you run the integration tests yourself and fix the issues?
Instructions here: https://github.com/GoogleContainerTools/jib/blob/master/CONTRIBUTING.md#code-reviews

@mbruggmann
Copy link
Contributor Author

The integration-tests caught an actual bug: the code was relying on ImageReference equality that wasn't implemented (added in the latests commit). Now it seems like Travis had what looks like an intermittent error though. Could someone with write access to the repo retrigger the Travis and Kokoro builds? Thanks

Copy link
Member

@briandealwis briandealwis left a comment

Choose a reason for hiding this comment

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

Thanks for your contribution!

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