Release Binaries & Source Tarballs With Submodules

jordan commented

2023-09-08 01:12:12 +00:00

Owner

It would be great to get some continuous integration going for Telodendria. @lda had a nifty Matrix bot that would run CI on submitted patches, but alas, that no longer works.

I can think of two options for CI:

Use Gitea Actions. This would probably be preferable as it keeps everything tightly integrated on our Gitea instance, but currently our Gitea is too old (v1.18.5). When the OpenBSD port is updated, I will be sure to upgrade our instance so we can take advantage of new features.
Deploy a Jenkins instance that isn't dependent on the version of Gitea being used.

The goal is to test builds on different platforms automatically, of course, but I also would like to be able to ship binaries with releases, and CI would be a great way to ship binaries for a large number of platforms. I made a note in install.md that will have to be updated when we get this figured out.

It would be great to get some continuous integration going for Telodendria. @lda had a nifty Matrix bot that would run CI on submitted patches, but alas, that no longer works. I can think of two options for CI: - Use [Gitea Actions](https://docs.gitea.com/usage/actions/overview). This would probably be preferable as it keeps everything tightly integrated on our Gitea instance, but currently our Gitea is too old (v1.18.5). When the OpenBSD port is updated, I will be sure to upgrade our instance so we can take advantage of new features. - Deploy a [Jenkins](https://www.jenkins.io/) instance that isn't dependent on the version of Gitea being used. The goal is to test builds on different platforms automatically, of course, but I also would like to be able to ship binaries with releases, and CI would be a great way to ship binaries for a large number of platforms. I made a note in [`install.md`](https://git.telodendria.io/Telodendria/telodendria/src/branch/master/docs/user/install.md#release-binary) that will have to be updated when we get this figured out.

jordan added the

enhancement

label 2023-09-08 01:12:12 +00:00

jordan commented

2023-10-30 15:08:23 +00:00

Author

Owner

Gitea has now been updated to a sufficiently high version, and I have enabled Actions. I have yet to set up any runners, but we could theoretically begin writing an actions file that runs CI on the code and generates binary releases.

lda commented

2023-11-02 16:31:30 +00:00

Contributor

Just started playing around with actions a bit on a new branch.
I haven't gotten anything beyond a job to setup a basic build environment(gcc/clang+make+openssl/libressl(if not on Debian/Ubuntu)) though, everything around here is untested.

Just started playing around with actions a bit on [a new branch](https://git.telodendria.io/lda/telodendria/actions/runs/1). I haven't gotten anything beyond a job to setup a basic build environment(gcc/clang+make+openssl/libressl(if not on Debian/Ubuntu)) though, everything around here is untested.

jordan added this to the Telodendria v1.7.0-alpha5 project 2023-11-08 19:33:44 +00:00

jordan commented

2023-11-08 20:09:40 +00:00

Author

Owner

Let's make a list here of all the OS/platform combinations we want to build Telodendria on.

FreeBSD (amd64)
OpenBSD (amd64)
NetBSD (amd64)
Debian (Linux + glibc) (amd64)
Alpine (Linux + musl) amd64)
Windows (amd64)

Note that Gitea's act_runner must support the platform. Theoretically, anywhere Go is supported should work.

Feel free to add more in the comments here. I don't have access to any other architectures than amd64. I do have 2 Raspberry Pis, which could host runners for two platforms for arm64. That might be kind of nice.

Let's make a list here of all the OS/platform combinations we want to build Telodendria on. - [x] FreeBSD (amd64) - [x] OpenBSD (amd64) - [x] NetBSD (amd64) - [x] Debian (Linux + glibc) (amd64) - [x] Alpine (Linux + musl) amd64) - [ ] Windows (amd64) Note that Gitea's `act_runner` must support the platform. Theoretically, anywhere Go is supported should work. Feel free to add more in the comments here. I don't have access to any other architectures than amd64. I do have 2 Raspberry Pis, which could host runners for two platforms for arm64. That might be kind of nice.

jordan commented

2023-11-08 20:39:54 +00:00

Author

Owner

We will want workflows for all of the following:

On Push: Just compile everything and spit out any warnings
On Release: Package up binaries nicely and attach them to the release.

We will want workflows for all of the following: - **On Push:** Just compile everything and spit out any warnings - **On Release:** Package up binaries nicely and attach them to the release.

jordan commented

2024-01-12 01:48:16 +00:00

Author

Owner

Note that Cytoplasm also needs CI, and that Telodendria CI should pull Cytoplasm release tarballs from Gitea.

jordan commented

2024-01-12 19:58:03 +00:00

Author

Owner

I just set up an Alpine v3.19 x86_64 runner. I will add more runners once I have thoroughly debugged CI scripts.

jordan referenced this issue

2024-01-12 19:59:09 +00:00

WIP: Basic actions workflow for building Telodendria #41

jordan commented

2024-01-14 02:06:35 +00:00

Author

Owner

Okay, CI is up and running. I just have figure out what I want to do about release binaries, because currently we would have to ship both the telodendria binary and libCytoplasm.so, unless I can figure out an easy way to bake libCytoplasm.a into the telodendria binary. Then our only dependency will be on the libc and OpenSSL/LibreSSL, which is fine because those are both typically built-in to the system.

I also want to generate a source tarball that includes Cytoplasm. By default, Gitea releases will not include submodules, so we will need a workflow that builds a source tarball for the created tag and attaches it to the Gitea release.

Okay, CI is up and running. I just have figure out what I want to do about release binaries, because currently we would have to ship both the `telodendria` binary and `libCytoplasm.so`, unless I can figure out an easy way to bake `libCytoplasm.a` into the `telodendria` binary. Then our only dependency will be on the libc and OpenSSL/LibreSSL, which is fine because those are both typically built-in to the system. I also want to generate a source tarball that includes Cytoplasm. By default, Gitea releases will not include submodules, so we will need a workflow that builds a source tarball for the created tag and attaches it to the Gitea release.

jordan changed title from ~~Continuous Integration & Release Binaries~~ to Release Binaries & Source Tarballs With Submodules

2024-01-14 02:06:52 +00:00

lda commented

2024-09-14 13:22:45 +00:00

Contributor

Just noting down something that may be worthwhile if we ever generate static binaries, because I did notice hurdles trying to run Cytoplasm-based projects with a static musl and OpenSSL (see this Parsee issue).

I think that if static Linux builds are to be done, we may just want to investigate into smaller SSL libraries(like possibly MbedTLS/wolfSSL) to do that job.

Just noting down something that may be worthwhile if we ever generate static binaries, because I did notice hurdles trying to run Cytoplasm-based projects with a static musl and OpenSSL (see [this Parsee issue](https://git.kappach.at/lda/Parsee/issues/6)). I think that if static Linux builds are to be done, we may just want to investigate into smaller SSL libraries(like possibly MbedTLS/wolfSSL) to do that job.

Release Binaries & Source Tarballs With Submodules #31