Add github action to generate reproducible builds

[ShahanaFarooqui]

Add a new GitHub Action to streamline our release process by generating reproducible builds via workflow.

• The action should be triggered on both tag push and workflow dispatch events.
• The action should produce builds for Fedora, Ubuntu Focal, Ubuntu Jammy, and Ubuntu Noble, along with a .zip file for upload on the release page.
• This will also require to integrate functionality from tools/repro-build.sh
• Remove unused Dockerfiles and scripts for a cleaner codebase. But do not delete the build-release and repro-build scripts as they are still essential for release verification and signing by other team members.

[s373nZ]

Hello, I'm interested to look into this. Likely I'll have some additional questions or discover some intricacies as I get into it, but please feel free to assign to me.

[s373nZ]

For historical context, from Discord:

Is it fair to say the goal is to automate as much as possible from https://docs.corelightning.org/docs/release-checklist specifically the Releasing -rc1 section?
[Shahana]: Yes, that’s correct.

You mentioned in one of our previous calls you thought we could do away with some of the Dockerfiles by using buildx. Can you expand a little further on what you had in mind? Do you have a general idea of that Dockerfiles or scripts that could be removed?
[Shahana]: Actually, I don’t have a clear idea yet, and I’m not even sure if any are removable. We currently have nine Dockerfiles and numerous scripts. My goal was just to evaluate whether all of them are necessary:
Dockerfile
contrib/docker/Dockerfile.builder
contrib/docker/Dockerfile.builder.fedora
contrib/docker/Dockerfile.tester
contrib/docker/Dockerfile.ubuntu
contrib/reprobuild/Dockerfile.focal
contrib/reprobuild/Dockerfile.jammy
contrib/reprobuild/Dockerfile.noble

Do we need to be concerned with building the Docker images (found when glancing through the build-release.sh file.
[Shahana]: No, this has already been automated in .github/workflows/docker-release.yml.

My first inclination is to try and perform the builds using a similar (if not the same) method to the new repro.yml nightly process. Maybe even try to abstract that into a repeatable action. As the repro-build.sh script was implicitly used in the nightly builds, the new process seems to be mainly the build-release.sh script.
[Shahana]: Yes, leveraging the existing process makes sense.

[s373nZ]

@ShahanaFarooqui During this first iteration, I've run across the fact that the sign target requires a default gpg key configured. Are you and the team comfortable with configuring a signing key as a secret variable in Github and having the action write it into configuration?

[ShahanaFarooqui]

Let us keep the signing process manual.

[s373nZ]

Let us keep the signing process manual.

That's fine with me. However, while researching this, I've starting having pipe dreams of having the CI in future iterations:

1. Create the release draft
   • https://github.com/actions/create-release
2. Upload the artifacts to the release
   • https://github.com/actions/upload-artifact
   • https://github.com/marketplace/actions/upload-assets-to-a-release

Obviously this is out of scope for this issue as written, but doing the signing outside CI might be an obstacle to that idea in the future. Just something to think about...

[ShahanaFarooqui]

Uhh, you made a valid point.

@cdecker, We could benefit from your input on this.