feat: Add reproducible Debian package builds and distribution #7617
Conversation
MoeMahhouk
changed the title
| @@ -0,0 +1,188 @@ | |||
| name: reproducible-build | |||
There was a problem hiding this comment.
I'd avoid imposing a responsibility for verifying reproducibility to third-parties (Lighthouse team in this case). Those who have reproducibility requirements should independently verify it relying on their infra.
There was a problem hiding this comment.
The variance in the environment is not sufficient to say that the builds are reproducible. Check out how Debian independently verify reproducibility by building on different OSes with a variable set of tools.
There was a problem hiding this comment.
I also followed here the steps of reth and how they are doing it here https://github.com/paradigmxyz/reth/blob/main/.github/workflows/reproducible-build.yml
However, good point on if the lighthouse team would want this to be as part of their workflow or not. I would leave it for them to decide and then we can re-iterate on what the best way to do it
| @@ -0,0 +1,142 @@ | |||
| name: release-reproducible | |||
There was a problem hiding this comment.
Can we make reproducible builds a default for Lighthouse? Not an additional target requiring extra effort to support
There was a problem hiding this comment.
I created a separate workflow for the reproducible container builds as separation of concerns similar to what the reth team did here https://github.com/paradigmxyz/reth/blob/main/.github/workflows/release-reproducible.yml
MoeMahhouk
force-pushed
the
deb-packaging
branch
from
d950bee to
1519838
Compare
MoeMahhouk
force-pushed
the
deb-packaging
branch
from
1519838 to
211063a
Compare
simplified the lighthouse systemd service
| echo " - Release Suite: run $RELEASE_SUCCESS" | ||
| echo " - docker-reproducible: run $DOCKER_SUCCESS" | ||
| echo "should_proceed=true" >> $GITHUB_OUTPUT | ||
| else |
There was a problem hiding this comment.
This block does not actually wait for the completion of another workflow that this workflow depends on, it checks the status and exits if not ready.
As per GH docs when multiple WFs specified in workflows: [Release Suite, docker-reproducible] only one needs to complete, the other could still be running when release-reproducible is triggered. So we need to actually wait for the completion periodically checking the status of a WF.
There was a problem hiding this comment.
yes exactly, that is why I introduced the should_proceed variable which will only be true if both of those workflows ran and completed successfully.
Therefore, if only one ran and the other didnt, it will immediately stop this workflow to spare resources and run again once the second workflow finalizes successfully. Check out the types: [completed] above
|
@MoeMahhouk is this still a work in progress? |
@chong-he , yes it is. I will open it up for review this week after clearing up some feedback. |
|
cargo sort CI is failing, can you fix this?
cargo sort CI is failing, can you fix this? |
chong-he
added
waiting-on-author
Done |
chong-he
added
ready-for-review
|
I have a look at this PR, from my understanding, this will include a I am wondering what is the use case here? |
4 participants
Issue Addressed
This pull request introduces workflows and configuration updates to automate the building, testing, and releasing of reproducible Debian packages for the Lighthouse project. Below are the key changes grouped by theme:
New GitHub Actions Workflows
.github/workflows/release-deb.ymlto automate the building, testing, and releasing of reproducible Debian packages for multiple architectures (x86_64andaarch64). Includes steps for dry-run testing, artifact uploads, and checksum generation.Proposed Changes
Additional Info
This is an incremental work on #7614 and requires it to be merged first
close #7618