-
2025-01-17 11:41:25
**Holy crap what a week! I can't believe the amount of progress that came out of just these few days. And a special thanks to nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 for making this possible with me! Alright, let's get into it...**
## GitHub Blossom Upload Action
I started this week working out the GitHub action for blossom uploads, solving some issues with dependencies, which turned out to just be me not bundling my dependencies with the my build output. So anyway I ended up publishing it and sharing it with all of you.
nostr:nevent1qvzqqqqqqypzpwa4mkswz4t8j70s2s6q00wzqv7k7zamxrmj2y4fs88aktcfuf68qy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqzskk7na9x9cgnzpvz7xufdn2y8wqxf00rnq7jg75z86lk30l6plspy9e9u
## Pipeline runner
### The plan
I can't believe all of this happened just this week. I worked out a plan with nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 to first create a DVM that would be able to clone a given ngit(!) repository and just print the contents of any given pipeline `.yaml` file that resides inside that repository.
The DVM would have the following inputs
- git url (or Nostr address)
- branch
- pipeline (path to yaml)
### Proof of Concept
I was able to repurpose a dvm-git-watcher that i'd created earlier to create the DVM to run the pipeline. Created a POC where the CI runner actually takes the pipeline, executes it and gives back a response and decided to put up a little video demo:
https://cdn.satellite.earth/43463990dd11c9506989e5eda915757cf3ec1b32e8d472579cd2ee18d5685f0d.mp4
### Some improvements
Wednesday I added a NIP-89 announcement to the DVM where it just advertizes its existence in hopes of some validation that it is real, and that it is actually useful, and it hopes to be used and talk with other npubs to not be lonely...
So then i figured it was time to package it into an easier to distribute package, a Docker container. That would allow me to include the required tools, namely ngit-cli and the 'act' cli (used to run the pipeline).
### Troubles 😱
Adding the precompiled version of ngit got me into trouble with this error:
```shell
Error: Cloning into 'tmp/1ca8af464df5fc648b77db14e0e5e35ff64d6627a690e138e19298dd56573274'...
/app/ngit//git-remote-nostr: /usr/local/lib/libc.so.6: version `GLIBC_2.38' not found (required by /app/ngit//git-remote-nostr)
/app/ngit//git-remote-nostr: /usr/local/lib/libc.so.6: version `GLIBC_2.39' not found (required by /app/ngit//git-remote-nostr)
fatal: remote helper 'nostr' aborted session
```
I didn't really know how to proceed as it could be a Docker issue, a Deno issue, or an ngit issue.
Luckily nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 knows his shit and saved me here. It turned out to be an issue that had to do with the ngit binary. Because ngit is compiled on a recent ubuntu version, it depended on some packages that the linux version my Docker image was based on did not have. Thus it failed.
Our solution was to compile ngit instead of using the existing binary, which took some trial and error to get working but eventually it did. It slowed down the build process significantly but alas, at least it works now!
### Moving on
After ngit worked I added the 'act' runner to the docker image and was able to control the host system's docker so it can run the isolated environments that have the pipelines run inside.
And so I was able to package up the thing, able to run on any machine, which led me to this little demo:
nostr:nevent1qqs9486y7cs6a9h7n4sk7sdv52qvuqyp80rj0eyg6zt7htfyt9wh4wgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzpwa4mkswz4t8j70s2s6q00wzqv7k7zamxrmj2y4fs88aktcfuf68g4v3lk
The only issue I still have is getting the output of the pipeline properly fed back to the user. But that's some magic with log streams that I have zero experience with, so that's a nice challenge for next week! If you or anyone you know is a Stream magician, please let me know!
See you there!