Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix GH CI workflow #1810

Merged
merged 12 commits into from
Sep 11, 2024
Merged

Fix GH CI workflow #1810

merged 12 commits into from
Sep 11, 2024

Conversation

erubboli
Copy link
Member

Fix Github CI workflow

This pull request implements comprehensive CI workflows for building and packaging releases across multiple platforms. The enhancements include:

Release Types

For each platform, we now produce two distinct release packages:

  1. NodeGUI Package: Contains the Mintlayer Node GUI application.
  2. Tools Package: Includes Mintlayer Node and command line utilities.

Platform-Specific Builds

macOS

  • NodeGUI release:
    • Signed and packaged as a .dmg file for easy installation.
  • Tools package:
    • Provided as a .zip archive.

Linux

Three package formats are now available:

  • .zip: For universal compatibility.
  • .deb: For Debian-based distributions (Ubuntu, Debian, etc.).
  • .rpm: For Red Hat-based distributions (Fedora, CentOS, etc.).

Windows

  • NodeGUI release:
    • Packaged as a .zip file.
    • Also available as an installer (.exe).
  • Tools package:
    • Provided as a .zip archive.

Docker

  • Docker images are built and pushed to our repository.

Additional Notes

  • All builds are automated through our CI pipeline, ensuring consistency across releases.
  • Each artifact is accompanied by a SHA256 hash for verification purposes.
  • Release notes are automatically generated, listing all included files and their respective hashes.

@@ -0,0 +1,47 @@
name: Build Docker
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to put the release-related build-xxx files into a separate release subfolder.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like the idea but got this error from gh:

invalid value workflow reference: workflows must be defined at the top level of the .github/workflows/ directory

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like the idea but got this error from gh

Then I'd suggest to rename the files at least, giving them the "release-" prefix, so that it's clear what those jobs are for.

Comment on lines +39 to +41
<!-- Debugging (remove for production) -->
<key>com.apple.security.get-task-allow</key>
<false/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its set to false so its OK. when true it permits debugger

@@ -0,0 +1,231 @@
#!/bin/bash

set -e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also specify set -o nounset. Though it'll require refactoring the script a bit.


# Main execution
main() {
if [ $# -eq 0 ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-ne 2 ?

Cargo.toml Outdated
installers = []
# Target platforms to build apps for (Rust target-triple syntax)
targets = ["aarch64-apple-darwin", "x86_64-apple-darwin", "x86_64-unknown-linux-gnu", "x86_64-pc-windows-msvc"]

# Publish jobs to run in CI
pr-run-mode = "plan"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this line was also related to dist and should be removed

for binary in "${BINARIES[@]}"; do
cp target/${{ matrix.arch }}-unknown-linux-gnu/release/$binary Mintlayer_Node_linux_${{ steps.get_version.outputs.VERSION }}_${{ matrix.arch }}/
done
zip -r Mintlayer_Node_linux_${{ steps.get_version.outputs.VERSION }}_${{ matrix.arch }}.zip Mintlayer_Node_linux_${{ steps.get_version.outputs.VERSION }}_${{ matrix.arch }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw why zip? Previously we used tar.xz and it looks more linux-friendly

cat << EOF > debian-gui/usr/share/applications/mintlayer-node-gui.desktop
[Desktop Entry]
Name=Mintlayer Node GUI
Exec=/usr/bin/node-gui
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw,

  1. I wonder whether we should rename the binary before installing it into the system. E.g. to mintlayer-node-gui. IMO node-gui sounds too generic and confusing without a context.

  2. Also, why don't we provide a standalone version of node-gui anymore (i.e. just an executable in an archive) in addition to the deb/rpm? Some people (myself including) would prefer a standalone app.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO node-gui sounds too generic and confusing without a context.

Same for the deb/rpm that install command-line apps.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you; binaries should have a prefix to avoid conflicts when installed system-wide. However, implementing this change would break any existing scripts. It's a delicate matter, and I'm not sure we can make this change easily now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you; binaries should have a prefix to avoid conflicts when installed system-wide. However, implementing this change would break any existing scripts. It's a delicate matter, and I'm not sure we can make this change easily now.

I wonder whether we should publish the deb/rpm at all in such a case. At least for the command-line tools. Because not only those binaries have generic names, their --help output doesn't even mention they are related to Mintlayer. So users may not have any idea what has just been installed into their system.

Comment on lines 180 to 181
cp target/${{ matrix.arch }}-unknown-linux-gnu/release/$binary Mintlayer_Node_linux_${{ steps.get_version.outputs.VERSION }}_${{ matrix.arch }}/
done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The zip archive and packages have inconsistent naming for arm64 - the packages have the suffix "arm64" and the archive "aarch64". Not a big deal, but can be confusing for users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The zip archive and packages have inconsistent naming for arm64 - the packages have the suffix "arm64" and the archive "aarch64". Not a big deal, but can be confusing for users.

Same thing for x86_64 actually (the suffixes are x86_64 and amd64)

#
# Note that the Github Release will be created with a generated
# title/body based on your changelogs.
name: Build, Sign, and Release
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now builds and signs artefacts for every PR. It should be limited to release branches I guess


jobs:
build:
runs-on: ubuntu-latest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should use the latest image here, because it effectively determines the minimum version of glibc required by the binaries. E.g. I've checked your test binaries - according to objdump, node-daemon needs at least one symbol from glibc v2.34, while node-gui needs a symbol from v2.35.
Glibc v2.35 is the one used by Ubuntu 22.04, which is what "ubuntu-latest" currently means on GitHub Actions. But they'll update to 24.04 eventually and our next release may suddenly require even a newer version of a Linux distro.
For comparison, Debian 11 (which, as I've googled, will be supported until 08.2026), has glibc v2.31, so the binaries won't work there.
And RHEL 8 (supported until 2029) has glibc v2.28.

So at the very least I'd suggest to specify a concrete Linux distro here.
GitHub actions should still support ubuntu-20.04 (which uses glibc v2.31), we can use this one, so that the binaries work on Debian 11 at least.

An alternative solution might be to use one of the "manylinux" docker images, which are used to compile Python extensions. I've found this article where the author has successfully used one of the manylinux images with GitHub actions.


Or we may want to switch to using musl-libc targets, so that the binaries don't depend on glibc at all. Though those targets are still considered "Tier 2" so I'm not sure if it's a good idea (in any case, it's not a good idea to switch to musl in the current release).

P.S. We could also provide musl-based binaries in addition to glibc-based ones, so that people on older systems could have an alternative.

@erubboli erubboli merged commit 301bdde into master Sep 11, 2024
18 checks passed
@erubboli erubboli deleted the fix_workflow branch September 11, 2024 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants