crane rebase and mutate.Rebase set empty-valued platform fields

[micahyoung]

After rebasing, the rebased image has platform fields with empty values ("os":"", "architecture":"", "os.version":"", etc.) though the input images contained these fields with valid values.

Docker and k8s Linux containers allow pulling and running these platform-less images by adding their own platform but Windows containers fail to pull or run (which is how I noticed this issue).

It appears this is mostly implemented already in mutate.Time though some optional fields are missed (os.features, variant, features from platform struct).

I feel the expected behavior would be to copy all platform fields with values (spec'd under platform) from the new_base image to the rebased image.

I'll add a PR assuming there's no objection to the proposed behavior.

Repro:

# Local registry
docker run -p 5000:5000 -d --rm registry:2

# Tags to be used
original_image="localhost:5000/my-original-image"
rebased_image="localhost:5000/my-rebased-image"
old_base_image="alpine:3.11"
new_base_image="alpine:3.12"

# Build and push the original image
docker build . --tag ${original_image} -f <(cat <<EOF
FROM ${old_base_image}
RUN echo bar > /foo
EOF
)
docker push ${original_image}
docker rmi -f ${original_image}

# Rebase onto new base
crane rebase \
  --original ${original_image} \
  --old_base ${old_base_image} \
  --new_base ${new_base_image} \
  --rebased ${rebased_image}

# See missing fields on rebased image
crane config ${rebased_image} | jq ".os,.architecture"
## Output
""
""

# See existing platform fields on original and old base images
crane config ${original_image} | jq ".os,.architecture"
crane config ${old_base_image} | jq ".os,.architecture"
crane config ${new_base_image} | jq ".os,.architecture"
## Output
"linux"
"amd64"
"linux"
"amd64"
"linux"
"amd64"

[imjasonh]

This seems reasonable to me. @jonjohnsonjr wdyt?

[jonjohnsonjr]

I'm surprised that we're dropping any fields -- we should be preserving everything and just updating the things that need to change.

Agree this is a bug.

[micahyoung]

Thanks for the quick response! Would a PR from me be useful? I realize there might be some shared behavior between mutate.Time. And while it would not negatively affect projects I know of, are there any backward compatibility concerns with adding these fields back?

[jonjohnsonjr]

Would a PR from me be useful?

Definitely. Happy to merge a quick fix.

Ultimately I'd like to understand why we're dropping these fields, I don't think it's intentional. Doing what mutate.Time does by selectively adding them back to the config file seems error-prone, since we might miss something, but for now I think it's fine to get this unbroken.

And while it would not negatively affect projects I know of, are there any backward compatibility concerns with adding these fields back?

I think this is an uncontroversial change and wouldn't worry about backward compatibility.