Shell access for builds.sr.ht CI August 19, 2019 on Drew DeVault's blog

Have you ever found yourself staring at a failed CI build, wondering desperately what happened? Or, have you ever needed a fresh machine on-demand to test out an idea in? Have you been working on Linux, but need to test something on OpenBSD? Starting this week, builds.sr.ht can help with all of these problems, because you can now SSH into the build environment.

If you didn't know, Sourcehut is the 100% open/libre software forge for hackers, complete with git and Mercurial hosting, CI, mailing lists, and more - with no JavaScript. Try it out!

The next time your build fails on builds.sr.ht, you’ll probably notice the following message:

Screenshot of builds.sr.ht showing a prompt to SSH into the failed buildVM and examine it

After the build fails, we process everything normally - sending emails, webhooks, and so on - but keep the VM booted for an additional 10 minutes. If you do log in during this window, we keep the VM alive until you log out or until your normal build time limit has elapsed. Once you’ve logged in, you get a shell and can do anything you like, such as examining the build artifacts or tweaking the source and trying again.

$ ssh -t builds@azusa.runners.sr.ht connect 81809
Connected to build job #81809 (failed):
https://builds.sr.ht/jobs/~sircmpwn/81809
Your VM will be terminated 4 hours from now, or when you log out.

bash-5.0 $

You can also connect to any build over SSH by adding shell: true to your build manifest. When you do, the VM will be kept alive after all of the tasks have finished (even if it doesn’t fail) so you can SSH in. You can also SSH in before the tasks have finished, and tail the output of the build in your terminal. An example use case might be getting a fresh Alpine environment to test build your package on:

This was accomplished with a simple build manifest:

image: alpine/edge
shell: true
sources:
- https://git.alpinelinux.org/aports
tasks:
- "prep-abuild": |
    abuild-keygen -an

Since build manifests run normally in advance of your shell login, you can do things like install your preferred editor and dotfiles, pull down your SSH keys through build secrets, or anything else you desire to set up a comfortable working environment.

Furthermore, by leveraging the builds.sr.ht API, you can write scripts which take advantage of the shell features. Need a NetBSD shell? With a little scripting you can get something like this working:

With experimental multiarch support being rolled out, soon you’ll be just a few keystrokes away from an ARM or PowerPC shell, too.

I want to expand more on SSH access in the future. Stay tuned and let me know if you have any cool ideas!

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

Summary of changes for February

Hey everyone! This is the list of all the changes we've done to our projects and apps during the month of February. We'll also be reporting in our on position in the world, and on our future plans. Summary Of Changes Uxn, started working on a fa…

via Hundred Rabbits February 28, 2021

Contexts and structs

Introduction In many Go APIs, especially modern ones, the first argument to functions and methods is often context.Context. Context provides a means of transmitting deadlines, caller cancellations, and other request-scoped values across A…

via The Go Programming Language Blog February 24, 2021

Status update, February 2021

Hi! Once again my focus has been Wayland-related projects this month. A steady stream of improvements made it into wlroots: Xyene made the X11 clipboard code a lot more robust, bl4ckbone has made good progress on the upcoming Pixman-based software renderer, a…

via emersion February 22, 2021