Add Github action for build and test supporting multi-arch

[desaiuditd]

Attempts to fix #129

Platform/Architecture supported:

• linux-x64
• linux-arm64 (ARM machines - Raspberry Pi etc.)
• macos-x64 (Intel)
• macos-arm64 (Apple Silicon)

hledger steps in the pipeline are skipped for linux-arm64 platform.
Because hledger also doesn't support it yet. We can add it later, if needed.

The compilation and build is kept with dynamic linking as-is. Static linking was giving hard trouble during build time.

Workflow runs on master branch and all PRs raised against master branch.

Basic support for cache is added for build and package files:

• ghcup
• stack

Referenced from https://github.com/simonmichael/hledger/blob/master/.github/workflows/ci.yml#L133-L176
This can be improved here in this repo by linking the cache with ghc or stack resolver version. We can optimise it later, if needed.
For now, I did not want to hardcode Stack resolver version in the Github Action which is also declared in stack.yaml file.

The steps in the build job loosely follow what was already done in .circleci/config.yml file.

Last two steps in the job uploads the binary as artifact on the Github Action Job. Which can be downloaded as zip.

A release job is also added to create Github Release automatically.
Will trigger automatically after build-and-test, when a new tag is pushed manually.
E.g., https://github.com/desaiuditd/hledger-flow/releases/tag/v0.16.1

Binaries generated from the build job:

⇒ docker run --rm -it --volume "$(pwd):/srv" --platform=linux/amd64 debian:stable-slim bash
root@9bcec8adc392:/# cd /srv/
root@9bcec8adc392:/srv# ./hledger-flow-linux-x64 --version
hledger-flow 0.16.1 linux x86_64 ghc 9.10 e958ab543dd696d10a5ef30236a91d23b88cabfa

⇒ docker run --rm -it --volume "$(pwd):/srv" debian:stable-slim bash
root@783750d6e667:/# cd /srv/
root@783750d6e667:/srv# ./hledger-flow-linux-arm64 --version
hledger-flow 0.16.1 linux aarch64 ghc 9.10 2e0632abbddb3ed08f59aeee5a778630ed9dd303

⇒ ./hledger-flow-macOS-x64 --version
hledger-flow 0.16.1 darwin x86_64 ghc 9.10 e958ab543dd696d10a5ef30236a91d23b88cabfa

⇒ ./hledger-flow-macOS-arm64 --version
hledger-flow 0.16.1 darwin aarch64 ghc 9.10 e958ab543dd696d10a5ef30236a91d23b88cabfa

# file ./hledger-flow-linux-x64
./hledger-flow-linux-x64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=590e68333ecc1a99c256b2a48e81ce8b4b922cde, stripped

# file ./hledger-flow-linux-arm64
./hledger-flow-linux-arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=b5de4fbb72161c96f68331e0aebc38b814ce2d8f, stripped

⇒ file ./hledger-flow-macOS-x64
./hledger-flow-macOS-x64: Mach-O 64-bit executable x86_64

# file ./hledger-flow-macOS-x64 
./hledger-flow-macOS-x64: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

⇒ file ./hledger-flow-macOS-arm64
./hledger-flow-macOS-arm64: Mach-O 64-bit executable arm64

# file ./hledger-flow-macOS-arm64 
./hledger-flow-macOS-arm64: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

# ldd ./hledger-flow-linux-x64 
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fffff6d3000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fffff6b3000)
	libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fffff629000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fffff433000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffffffc8000)

# ldd ./hledger-flow-linux-arm64
	linux-vdso.so.1 (0x0000ffff80eef000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff80df0000)
	libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff80db0000)
	libgmp.so.10 => /lib/aarch64-linux-gnu/libgmp.so.10 (0x0000ffff80d10000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff80b50000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff80ea0000)

⇒ otool -L ./hledger-flow-macOS-x64
./hledger-flow-macOS-x64:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libffi.dylib (compatibility version 1.0.0, current version 40.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61439.120.27)
	/usr/lib/libcharset.1.dylib (compatibility version 1.0.0, current version 1.0.0)

⇒ otool -L ./hledger-flow-macOS-arm64
./hledger-flow-macOS-arm64:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libffi.dylib (compatibility version 1.0.0, current version 40.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61439.120.27)
	/usr/lib/libcharset.1.dylib (compatibility version 1.0.0, current version 1.0.0)

[apauley]

This looks like great work, thanks @desaiuditd

I'm reviewing it and will see how it runs etc, but hopefully we can merge it soon

[apauley]

Instead of tar, new Github action uploads a zip with built binaries into Github workflow artifacts, which can be downloaded.

I don't mind if it zip files or tar files, whichever is easier to implement.

I did not do static linking. It was giving some hard trouble during build time. So Kept dynamic linking as-is. Final binaries seemed to work with that.

This is fine, I like the idea of statically linked binaries, if it means that users don't have to worry about having the right version of some libraries on their system, but if the build system doesn't support it then I guess we just use dynamic binaries and move on

#129 (comment)

[desaiuditd]

@apauley

I don't mind if it zip files or tar files, whichever is easier to implement.

Eventually I ended up copying what was already done in hledger repo. They are doing tar files. So tar it is.

[apauley]

@desaiuditd Thanks for contributing the Github Action, I think it will make releases a bit easier. Would you like to add submit a PR adding your name to the list of contributors?

I'll do a minor release in a day or so, then we can also test what happens when a tag gets pushed

[desaiuditd]

@apauley Thanks. Done. #131

I'll do a minor release in a day or so, then we can also test what happens when a tag gets pushed

Sounds good 👍🏻

[apauley]

@desaiuditd The release worked very well, all artifacts were automatically attached. Thanks!

https://github.com/apauley/hledger-flow/releases/tag/v0.16.2

[desaiuditd]

@apauley Awesome! 🎉
New version with arm64 worked like a charm as well. 🙌🏻

[apauley]

@desaiuditd Glad to hear. How are you using hledger-flow that made you need this? You mentioned something about docker, while I think most people just run the binary directly on their host OS

[desaiuditd]

@apauley On the contrary, I prefer to use Docker containers on my host machine as much as possible. This is personal preference though. I understand not everyone wants to do that. Using Docker gives me consistent, isolated, reproducible and ephemeral environments to run my tools without polluting my host machine.

So I've got a custom docker image with hledger and hledger-flow installed combined. Which I use daily to perform my hledger specific tasks.