fix: remove shell wrap for exec form RUN commands

[RoryDunne-Voyager]

An old issue: earthly#2618 reared up recently when trying to use a Docker Hardened Image.

I went and found that the shellWrap function was always being called on the arguments passed to a RUN command so I added some guards for it. This does not affect things like IF statements or arg expansion. Though it could definitely be worth further discussion.

[gemini-code-assist]

Summary of Changes

Hello @RoryDunne-Voyager, 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 provides a crucial fix for the RUN command's exec form, preventing it from being erroneously shell-wrapped. This change significantly improves compatibility with environments such as Docker Hardened Images, which rely on precise command execution. The solution involves refining the conditional logic for shell wrapping and is thoroughly validated with a new dedicated test case.

Highlights

• Fix for Exec Form RUN Commands: This pull request resolves an issue where RUN commands specified in 'exec form' (e.g., RUN ["command", "arg"]) were inadvertently being shell-wrapped, leading to incorrect execution.
• Improved Compatibility with Docker Hardened Images: The fix addresses a problem that specifically affected environments like Docker Hardened Images, which require direct command execution without an intermediate shell, ensuring better compatibility.
• Conditional Shell Wrapping Logic: The core logic in earthfile2llb/converter.go has been updated to ensure that shell wrapping is only applied when explicitly intended, by checking the opts.WithShell flag before assigning and calling the shellWrap function.
• New Test Case Added: A new test target, run-exec-form-test, has been introduced in tests/Earthfile and tests/run-exec-form.earth to validate the correct behavior of exec-form RUN commands without unintended shell wrapping.

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 correctly addresses the issue of shell-wrapping exec-form RUN commands, which is particularly problematic for shell-less images. The changes in earthfile2llb/converter.go are logical, and the addition of a test case using a distroless image is an excellent way to verify the fix. I have one suggestion to enhance the implementation by restoring debugger functionality for exec-form commands, which appears to be unintentionally disabled by the current changes.

[janishorsts]

Can you please bump debian to 13? To avoid @renovate-bot from bumping this to

Suggested change

	FROM gcr.io/distroless/python3-debian12:latest
	FROM gcr.io/distroless/python3-debian13@sha256:cc3bb44755599d4c25c26c43b05761eeb1da2e779172cee258c2202ca071abfa

[RoryDunne-Voyager]

Is this digest hash correct? I'm seeing: gcr.io/distroless/python3-debian13@sha256:6a4de1cbdac6b94b74b71a33298a9c7fed918161ff686bd501bfe9454113ae58

[janishorsts]

My bad, sha provided by me is for distroless/java25-debian13. Please use the correct sha!

[janishorsts]

@RoryDunne-Voyager, can you please check the failing GHA jobs (all except Security / Go Vulnerabilities Report (push))? Your changes cause them.

PS. Initially, I assumed that user permissions were causing the failures.

[RoryDunne-Voyager]

@RoryDunne-Voyager, can you please check the failing GHA jobs (all except Security / Go Vulnerabilities Report (push))? Your changes cause them.

PS. Initially, I assumed that user permissions were causing the failures.

Yes, sorry for not getting to this sooner, I'm going to move this PR to WIP to fix.