NPE on parse json manifest from Nexus

Environment:

• Jib version: 2.6.0
• Build tool: gradle 6.6.1
• OS: Fedora Linux 32

Description of the issue: On simple gradle project which tried to push into Nexus docker repo (as far as I know) I got NPE in parsing response:

Caused by: java.lang.NullPointerException
        at com.google.cloud.tools.jib.registry.AbstractManifestPuller.getManifestTemplateFromJson(AbstractManifestPuller.java:148)
        at com.google.cloud.tools.jib.registry.AbstractManifestPuller.handleResponse(AbstractManifestPuller.java:96)
        at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:141)
        at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:115)
        at com.google.cloud.tools.jib.registry.RegistryClient.callRegistryEndpoint(RegistryClient.java:624)
        at com.google.cloud.tools.jib.registry.RegistryClient.pullManifest(RegistryClient.java:436)
        at com.google.cloud.tools.jib.registry.RegistryClient.pullManifest(RegistryClient.java:441)
        at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.pullBaseImages(PullBaseImageStep.java:221)
        at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:169)
        at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:67)
        at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
        at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
        at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        ... 1 more

Expected behavior: Sucessul create docker image

Steps to reproduce:

1. Create gradle project
2. Apply jib plugin, configure as provided below
3. Run build like: DOCKER_REGISTRY_HOST=repo.tddev.ru DOCKER_REGISTRY_USER=<user> DOCKER_REGISTRY_PASSWORD=<password> ./gradlew --no-daemon jib -S

jib-gradle-plugin Configuration:

jib {
    from {
        image = "${System.env.DOCKER_REGISTRY_HOST}/addressmaster/addressmaster-base-image:1"
        auth {
            username = System.env.DOCKER_REGISTRY_USER
            password = System.env.DOCKER_REGISTRY_PASSWORD
        }
    }

    to {
        image = "${System.env.DOCKER_REGISTRY_HOST}/adressmaster/addressmaster:test2"
        auth {
            username = System.env.DOCKER_REGISTRY_USER
            password = System.env.DOCKER_REGISTRY_PASSWORD
        }
    }

    container {
        // This directory cleaned in base image. See dockerfile for addressmaster-base-image
        appRoot = '/usr/local/tomcat/webapps/ROOT'

        creationTime = 'USE_CURRENT_TIMESTAMP'
    }
}

Additional Information:

Exception happened in com.google.cloud.tools.jib.registry.AbstractManifestPuller#getManifestTemplateFromJson:148:

      String mediaType = node.get("mediaType").asText();

In debuger I see JSON response and its look like:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:815aba580449129146c7c8dc1c391e6baf58a15d2f998b1f637b90ff17f06543",
    "size": 13744
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:614914de101de29ca3b28486323294a4f842322f4c9a263c11ec3b2a5f1c7806",
      "size": 23670839
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:15013438f31069ae0cf28eda6503e541dcd3cd5f05449c6e9bd6b6f9be2b153f",
      "size": 476675
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:ad4daa2e7055614a2e40d20f42b6b50040eb01ee74a8cb7ac8a6d62d14cd21c8",
      "size": 241
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:5ad1e2ec70b4ff459510b53694149be7e28962ebb37bffe16cd35e5c5b5510e5",
      "size": 258
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:fd2dddf47661e24cfde9a91e9a87dbeb0053d7b88dd64d548e802396619e88d2",
      "size": 142
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:d398c43fb94e3985d2ae32c869861443daf6b905a4bb64fabe7674d1af34c308",
      "size": 80734051
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:f6d67d01adb0f928978947dbac536bc4dbbcb67a8290317de5435e7ada153cad",
      "size": 160
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:baa9315d41c0282a09a51ef532c8529b4c6bafca78bedd999a7d4360911bd6a6",
      "size": 451486
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:96a8a162aa83d8f1d8c51745ca49cda6ce418ebf742b5b1a6f337e4edb4f6ebb",
      "size": 12142282
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:65e201012bb071d4ca7f24d15db7a8c4cc450853722b8df07e935048fe2defcc",
      "size": 146
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:44286c353cee2fbd528283f6d5fc7745b4c191e34c225343192286eb046ffb12",
      "size": 418
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:e0fea8918f6d5be0ab59a0de758f0d130f79c2bcaeab8fc30a4fe2e5bd30b7c7",
      "size": 161
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:ee81dae5b590e707cced1bbb160fa602db619f52c6386dd30f957723841d6fe2",
      "size": 5342378
    }
  ]
}

So mediaType key on top-level is not exists, only as config sub-key.

Really for me part:

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:815aba580449129146c7c8dc1c391e6baf58a15d2f998b1f637b90ff17f06543",
    "size": 13744
  },

looks like incorrect answer format from server side… How you think? Could it be handled on JIB side?

[chanseokoh]

Maybe you can pass --format docker or set BUILDAH_FORMAT=docker for podman build to build a Docker manifest. podman push also seems to have --format.

http://docs.podman.io/en/latest/markdown/podman-build.1.html https://github.com/containers/podman/blob/master/docs/source/markdown/podman-push.1.md

Not sure if it’s free of issues (e.g., I just saw https://github.com/containers/buildah/issues/2317). But I guess it’s basically working.

[chanseokoh]

@Hubbitus thanks for the detailed report.

Initially I thought not having mediaType at the top-level for manifest is wrong. But interestingly, unlike the Docker manifest spec, the OCI manifest spec doesn’t indicate that mediaType is “required” but only “reserved” for compatibility. Indeed, the example in the spec doc doesn’t have mediaType. So it’s on us to fix the issue.

I think you have control over the base image .../addressmaster/addressmaster-base-image:1. As a workaround, you can rebuild the image using a different tool that generates mediaType and re-push the image. For example, maybe docker build using Dockerfile with a single-line FROM .../addressmaster/addressmaster-base-image:1 followed by docker push will create and push a Docker manifest (haven’t tested).