Github Actions for NoM repos

Development ╰ Funding | Staging
1

I’ve started a discussion with @sol and we agreed that the best solution for releasing binaries would be to setup a proper CI/CD solution on each repo.

I started to research CI/CD solutions and I think that Github Actions are the natural solution to automatically build, test and deploy directly from the source code since it’s hosted on Github. And the best part is that it’s free.

Besides basic actions for environment setup, we can add custom Github Actions to add a checksum list or sign binaries and verify dependency and source code integrity.

We can even build Syrius for all platforms by combining actions that will add the necessary libraries and will output a MacOS DMG, a Windows installer or a Linux package.

No more complicated scripts or third party tools and for future we can even publish releases everywhere.

8 Likes
2

@sol recommended to start with the C/C++ libraries first that are dependencies for other projects (znn-cli, Syrius, znn-controller) and I think it’s a great idea.

I’ll familiarize myself with Github actions and start creating workflows for each repository.

4 Likes
3

Happy to announce that we have a complete Github Actions workflow that is live for go-zenon.

It cross-compiles, archives, computes checksums and uploads znnd and libznn for every major platform such as windows/amd64, linux/amd64, linux/arm64, darwin/amd64, darwin/arm64 and even universal binaries for darwin that include both amd64 and arm64 slices.

I invite you to test the releases and I’ll proceed to configure Github Actions for all other repos.

10 Likes
4

That’s awesome! Thanks for setting this up! :fire:

1 Like
5

I’ve tested:

  • libznn-windows-amd64
  • libznn-linux-amd64
  • znnd-linux-amd64
  • znnd-linux-arm64*

They’re working well on my end!
* Runs but hasn’t synced any momentums; this could be due to a resource constraint in my setup.

Do you plan on making other changes to the cicd branch?

1 Like
6

Thank you! The libznn embedded node takes a little bit longer to initialize everything before syncing with the network. In Syrius it takes around 3-4 minutes depending on the specs of your machine before it starts syncing.

I think caching would improve build times, but other than that it’s ready for a PR.

7

I didn’t experience a sync initiation delay in Syrius with my Windows/Linux setups, even when starting from height 0.
The embedded node started up as expected, for me.

Is there a Github Action that would permit us to update the /blobs/ directories directly or are we limited to creating Github Releases?

8

sorry I missed this post. this is very exciting. I will try to test out today.

1 Like
9

Started working on the znn-pow-links-cpp. The workflow will be deployed in the cicd branch, as usual.

4 Likes
10

Happy to announce that we have releases for the znn-pow-links-cpp for the following (OS/arch):

  1. Windows x86_64
  2. Linux x86_64
  3. Darwin x86_64/arm64
  4. Android arm64-v8a

Bonus 1: Apple xcframework that contains iOS, iOS simulator and MacOS frameworks
Bonus 2: WebAssembly + Javascript

Also fixed a minor issue that impacted libznn (the embedded node could not be stopped properly). Now it is fixed.

Please test all releases properly so we can catch bugs like this.

6 Likes
11

Also managed to create releases for argon2_ffi similar to znn-pow-links-cpp and for znn_controller_dart that only supports linux-x86_64 for the moment.

Having all those things in place, the next step is to build syrius for Windows x64 and MacOS universal and hopefully Linux x64. I’ll keep you updated with my progress.

7 Likes
12

Can you also test znn-cli and znn-controller?

Thank you in advance!

PS Also added a test workflow for znn_sdk_dart.

2 Likes
13

I’m getting a linux-kernel-headers error on a fresh install of Ubuntu 22.04. I will try to correct this error and run again. I’ve never gotten this error on 20.04.

x3639@x3639-virtual-machine:~$ sudo ./znn-controller 
Running ZNN Controller with superuser privileges
ZNN Node Controller v0.0.3
Gathering system information ...
System info:
Shell: bash
User: x3639
Host: x3639-virtual-machine
Operating system: linux
OS version: Linux 5.15.0-50-generic #56-Ubuntu SMP Tue Sep 20 13:23:26 UTC 2022
Available CPU cores: 4
Dart runtime: 2.18.6 (stable) (Tue Dec 13 21:15:14 2022 +0000) on "linux_x64"
IP address: REMOVE
  1) Deploy
  2) Status
  3) Start service
  4) Stop service
  5) Resync
  6) Help
  7) Quit
Select an option from the ones listed above
 1
Running on a machine with 4 core(s) and 4 GB RAM
It is recommended to have a minimum 4 cores and 4 GB RAM for running the Deploy process
Are you sure you want to proceed with the deployment process? (Y/n): y
Checking NTP service configuration ...
Preparing go-zenon.service service configuration ...
go-zenon.service service not detected
Configuring go-zenon.service ...
Installing Linux prerequisites ...
Git not detected, proceeding with the installation
Error! Could not install linux-kernel-headers
x3639@x3639-virtual-machine:~$
14

Looks like I was able to correct this by simply running

sudo apt-get update
sudo apt-get upgrade
15

@aliencoder New error. I got through the header error by update / upgrade. Ran again and got the following error.

Select an option from the ones listed above
 1
Running on a machine with 4 core(s) and 4 GB RAM
It is recommended to have a minimum 4 cores and 4 GB RAM for running the Deploy process
Are you sure you want to proceed with the deployment process? (Y/n): y
Checking NTP service configuration ...
Preparing go-zenon.service service configuration ...
go-zenon.service service detected
Installing Linux prerequisites ...
Git not detected, proceeding with the installation
Go not detected, proceeding with the installation ...
Preparing to download Go ...
Checking Go download ...
Unpacking Go ...
Cleaning downloaded files ...
Preparing to clone go-zenon ...
znnd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=9b0d1e9fd4e4a6feac1cdaf851de265cf5060ad6, for GNU/Linux 3.2.0, stripped

Unhandled exception:
[Zenon SDK Exception: Library libargon2 could not be found, #0      initArgon2.<anonymous closure> (package:znn_sdk_dart/src/argon2/argon2.dart:46)
#1      Argon2FfiFlutter._loadLib (package:argon2_ffi_base/src/argon2_ffi_impl.dart:160)
#2      new Argon2FfiFlutter (package:argon2_ffi_base/src/argon2_ffi_impl.dart:92)
#3      initArgon2 (package:znn_sdk_dart/src/argon2/argon2.dart:15)
#4      KeyFile._encryptEntropy (package:znn_sdk_dart/src/wallet/keyfile.dart:95)
<asynchronous suspension>
#5      saveKeyStoreFunction (package:znn_sdk_dart/src/wallet/manager.dart:22)
<asynchronous suspension>
]
#0      KeyStoreManager.saveKeyStore.<anonymous closure> (package:znn_sdk_dart/src/wallet/manager.dart:54)
#1      _RootZone.runUnaryGuarded (dart:async/zone.dart:1586)
#2      _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339)
#3      _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271)
#4      _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:774)
#5      _StreamController._add (dart:async/stream_controller.dart:648)
#6      _StreamController.add (dart:async/stream_controller.dart:596)
#7      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:192)

I can see the libargon2_ffi.so file after I unzip the file

image
image3052×1232 408 KB

16

I tested on 20.04 and got the same error message.

17

znn-cli works as expected on linux.

1 Like
18

I tested znn-cli and znn-controller on Linux amd64.
The binaries and libraries worked but I had to rename argon2 in both instances to libargon2_ffi_plugin.so.

znn-cli: I was able to create a new wallet and execute pow for a transaction.
znn-controller: I was able to spin up a new node.

Great progress so far!

1 Like
19

Same error

image-32
image-321094×546 29.2 KB

1 Like
20

Just noticed Sol Sanctum existence. Retrying tomorrow

2 Likes