Release Binaries & Source Tarballs With Submodules #31

Open
opened 2023-09-07 20:12:12 -05:00 by jordan · 7 comments
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-07 20:12:12 -05: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.

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.
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 14:33:44 -05: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.
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.
Author
Owner

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

Note that Cytoplasm also needs CI, and that Telodendria CI should pull Cytoplasm release tarballs from Gitea.
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.

I just set up an Alpine v3.19 x86_64 runner. I will add more runners once I have thoroughly debugged CI scripts.
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-13 21:06:52 -05:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Telodendria/Telodendria#31
No description provided.