Support building multi-platform OCI index

[rquinio]

Fixes #2748 🛠️ (revival of #3975)

Removes the limitation of building OCI indexes when using multi-platform.
Re-uses the existing configuration ImageFormat = Docker vs OCI to determine the format of the manifest list/index.

[gemini-code-assist]

Summary of Changes

Hello @rquinio, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances Jib's multi-platform image building capabilities by introducing support for OCI image indexes. It involves a targeted refactoring of the manifest generation mechanism to intelligently produce the correct manifest type based on user configuration, ensuring Jib remains versatile and compliant with modern container image specifications. The changes are thoroughly validated with new tests and reflected in the project's documentation.

Highlights

• Multi-platform OCI Index Support: This pull request enables Jib to build and push multi-platform OCI image indexes, removing a previous limitation where only Docker manifest lists were supported for multi-platform builds. This addresses issue Enable OCI multi-platform image building #2748.
• Refactored Manifest Generation Logic: The core logic for generating manifest lists has been refactored in ManifestListGenerator.java to dynamically create either Docker manifest lists (V22ManifestListTemplate) or OCI image indexes (OciIndexTemplate) based on the configured image format. This re-uses existing configuration to determine the output format.
• Updated Documentation: The docs/faq.md file has been updated to reflect the new capability, removing the statement that OCI image indices are not supported for multi-platform builds.
• Comprehensive Testing: New integration tests (JibIntegrationTest.java) and unit tests (BuildManifestListOrSingleManifestStepTest.java, ManifestListGeneratorTest.java) have been added to validate the correct generation and handling of multi-platform OCI indexes.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for building multi-platform OCI indexes, removing a previous limitation. The changes include refactoring ManifestListGenerator to handle both Docker manifest lists and OCI indexes, and adding corresponding integration and unit tests. The implementation looks good, but I've found a few issues in the tests related to test isolation and reliance on execution order, which could lead to flaky builds. I've also suggested a minor refactoring in ManifestListGenerator for better code clarity. Overall, a solid contribution that extends Jib's multi-platform capabilities.

[rquinio]

/gemini review

[gemini-code-assist]

Code Review

This pull request removes the limitation of building multi-platform OCI indexes, which is a great enhancement. The changes are well-structured, including updates to the core logic, documentation, and the addition of integration and unit tests to cover the new functionality. I have a few suggestions to improve test robustness and for minor code cleanup.

[rquinio]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for building multi-platform OCI indexes, which is a great enhancement. The changes in ManifestListGenerator are well-structured, separating the logic for Docker manifest lists and OCI indexes. The new and updated tests, including the integration test, effectively cover the new functionality.

I have one suggestion to improve the robustness of the new integration test by making assertions independent of the order of manifests in the index. Overall, this is a solid contribution.

[gemini-code-assist]

The current assertions rely on the order of manifests in the manifest list, which could make the test fragile if the underlying implementation changes how platforms are ordered. To make the test more robust, I suggest verifying the platforms in an order-independent way. For example, you could collect the architectures into a Set and assert its contents, and then verify the OS for all manifests.

Suggested change

	OciIndexTemplate.ManifestDescriptorTemplate.Platform platform1 =
	manifestList.getManifests().get(0).getPlatform();
	OciIndexTemplate.ManifestDescriptorTemplate.Platform platform2 =
	manifestList.getManifests().get(1).getPlatform();
	Assert.assertEquals("arm64", platform1.getArchitecture());
	Assert.assertEquals("windows", platform1.getOs());
	Assert.assertEquals("amd64", platform2.getArchitecture());
	Assert.assertEquals("windows", platform2.getOs());
	java.util.Set<String> architectures =
	manifestList.getManifests().stream()
	.map(manifest -> manifest.getPlatform().getArchitecture())
	.collect(java.util.stream.Collectors.toSet());
	Assert.assertEquals(ImmutableSet.of("arm64", "amd64"), architectures);
	for (OciIndexTemplate.ManifestDescriptorTemplate manifest : manifestList.getManifests()) {
	Assert.assertEquals("windows", manifest.getPlatform().getOs());
	}

[rquinio]

Personally I prefer the current version, so that if the underlying implementation changes in Jib we see the impact somewhere.

[rquinio]

@diegomarquezp @mpeddada1 I guess the PR is ready for a human review, if you have time. The change is relatively small, but would help Jib support better the OCI standard, as multi-arch support comes almost for free with OpenJDK containers.