NPE on parse json manifest from Nexus

[Hubbitus]

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]

@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).

[Hubbitus]

Glad to hear that will b fixed, thank you.

The problem with addressmaster-base-image it was just pushed by podman. Are there some options to control how to manifest created for image and pushed?

[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 containers/buildah#2317). But I guess it's basically working.

[Hubbitus]

@chanseokoh, thank you for the workaround suggestion! It looks like pushing base image with podman push --format=docker repo.tddev.ru/addressmaster/addressmaster-base-image:1 works.

[chanseokoh]

@Hubbitus Jib 2.7.0 has been released with this fix! Should be able to handle OCI manifests (and indices) that has no mediaType defined.