fix: reproducible build

[think-in-universe]

It's required to set SOURCE_DATE_EPOCH=0 for some crates.

The docker image digest db6effdef6c139e45b680be9f3c40def73847ea08ac93629fcacb6969be113b0 is now reproducible.

[cursor]

You have run out of free Bugbot PR reviews for this billing cycle. This will reset on January 9.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[gemini-code-assist]

Summary of Changes

Hello @think-in-universe, 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 addresses the reproducibility of builds by implementing a standard mechanism to control timestamps within the Docker build process. By setting the SOURCE_DATE_EPOCH environment variable, the PR ensures that subsequent builds of the same source code will produce identical artifacts, regardless of when the build is executed. This change is crucial for maintaining consistency and verifiability of the build output.

Highlights

• Reproducible Builds: Introduced the SOURCE_DATE_EPOCH environment variable within the Dockerfile to ensure build reproducibility.
• Timestamp Standardization: Set SOURCE_DATE_EPOCH to 0 to standardize timestamps for all build artifacts, preventing variations due to build time.

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 aims to make the Docker build reproducible by setting SOURCE_DATE_EPOCH. The change correctly sets this for the builder stage, which is a good improvement. My review includes one suggestion to also apply this setting to the runtime stage. Build arguments and environment variables are not inherited across stages in a multi-stage Dockerfile, so adding it to the runtime stage is necessary to ensure operations within that stage are also reproducible, thus making the final image fully reproducible.

[claude]

Code Review

Change Summary:
This PR adds SOURCE_DATE_EPOCH=0 to the Docker build stage to ensure reproducible builds by standardizing timestamps in build artifacts.

Analysis:

The change is minimal and focused - adding ARG/ENV for SOURCE_DATE_EPOCH at lines 34-35 in the Dockerfile. This is a standard practice for reproducible builds.

Critical Issues: NONE

This change is safe and follows best practices for reproducible builds:

✅ Correct placement - Set before COPY and RUN cargo build commands, ensuring it affects the Rust compilation process

✅ Standard approach - SOURCE_DATE_EPOCH=0 is the conventional value for deterministic builds (Unix epoch start)

✅ No runtime impact - Only affects build-time artifact generation, not runtime behavior

✅ No breaking changes - The binary functionality remains identical, only timestamps in metadata change

Minor observations (non-blocking):

1. Build cache consideration: This change may affect Docker layer caching since the environment variable is set, but this is acceptable for reproducibility goals.

2. Value choice: Using 0 is common, though some projects use the commit timestamp. The choice of 0 is simpler and equally valid.

Recommendation:

✅ APPROVED - This is a clean, focused change that improves build reproducibility without introducing any risks. Safe to merge.

---

Review focused on critical production safety, logic flaws, performance issues, and Rust-specific concerns per repository guidelines.

[Copilot]

Pull request overview

This PR enhances the reproducible build capability by setting the SOURCE_DATE_EPOCH environment variable to ensure consistent timestamps across builds, complementing existing Rust compiler flags for reproducibility.

Key Changes:

• Added SOURCE_DATE_EPOCH environment variable with default value of 0 in the builder stage

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Additional Review Note

I notice the workflow file includes a change that adds the fix/repro-build branch to the build triggers:

branches:
  - main
  - fix/repro-build  # ← This line

Question: Is this intentional for testing purposes, or should it be removed before merge?

Recommendation: If this was added to test the reproducible build on this PR branch, it should be removed before merging to main. Otherwise, every commit to a feature branch named fix/repro-build will trigger production build workflows.

Not blocking if this is intentional for a specific reason, but wanted to flag it for consideration.

---

Previous review stands: The Dockerfile changes are ✅ approved and safe to merge.