Faster, affordable, Github Actions

We're introducing Github Runners support, built on top of our Ephemeral cluster infrastructure.

Connect your Github Organization with your Namespace Workspace, change your workflow to target a nscloud runner, and you're done!

• Faster each workflow gets more compute capacity by default.
• Affordable when using Namespace's managed Github Runners you are not spending Github Action minutes.
• Integrated All of Namespace features are enabled by default, including Remote Builders and Ephemeral Clusters.
• And you can even SSH into a machine of an ongoing (or previous) run.

Why would I want managed Runners?

We knew you would ask! As always, the answer is: it depends. GitHub offers generous free plans for private repositories. But there are many caveats that you need to be aware of. First of all, you can easily run out of the 2000 free minutes. Then, their free plan only allows up to 2-core machines. That is, if you need more computing resources, you start paying. The 500 MB of free storage includes both packages and artifacts. So, if you rely on caching build layers and Docker images, those might not be enough, and the limit is not reset every month! On the good side, GitHub does not charge the usage of self-hosted runners.

Namespace Runners can give you more control over the machine shapes you need, and they run in an integrated environment. The Namespace environment is configured to use our integrated Container Registry and image cache. Also, Docker builds are set by default to run inside a Remote Builder machine, which is always beefier than the Runner instance itself. The environment is designed to provide optimal CI performance and speed up your workflows.

In a nutshell, with Namespace, you can get a unified CI environment with performant tools you need to compose your CI/CD pipeline the way you find more appropriate.

I will run my own self-hosted Runner then!

You can, but managing the infrastructure is complicated, expensive, and keeping it secure is hard! You will likely get a major cloud provider to run virtual machines that become your runners. The way GitHub Runners work is that they process one job at a time. So, each VM can process at most one concurrent job. This leads to inefficient resource allocation and - very quickly - to an overprovisioned infrastructure that burns your money.

The natural solution would be to pack the Runner process inside a container and run it instead. As the Actions Runner Controller does for Kubernetes. The solutions that allow you to run Docker or Kubernetes within a container often require either a privileged container or a shared Docker socket, which both use the host's root and can compromise your infrastructure.

With Namespace Runners, you can avoid all these hurdles. We manage the infrastructure so you can focus on delivery features for your customers. Our Runners are powered by ephemeral micro VMs that boot in few seconds and remove themselves immediately after the CI job completes. The VM-level isolation provides a full root environment, allowing you to run securely Docker builds, Kubernetes, or any other tool you may need.

Step-by-step example

Let's see the Namespace Runners in action.

If you want to follow the below steps, you need:

1. A GitHub Organization
2. A private repository
3. A GitHub Action workflow

1 Install Namespace GitHub App

Our backends need to get a webhook notification whenever you trigger a new job on GitHub Actions so that it can create new runners. Also, it needs permission to register the runners under your GitHub Organization. Our Namespace App manages those steps automatically for you.

Go to the Integrations tab in the Namespace dashboard.

Then, install our GitHub App into your selected GitHub Organization.

Follow the installation flow until the end. GitHub will ask you to confirm the permissions and the repository accesses. To limit the scope where Namespace Runners can be used, you can select a subset of your repositories.

If everything went through okay, you should see your GitHub Organization on the Integrations page. As you can see, mine is gmichelo-dev.

2 Migrate workflows to Namespace Runners

We will replace the current runner label with our nscloud label to tell GitHub to use Namespace Runner.

By default, the nscloud label will create a 4 vCPU 4 GB of memory amd64 instance.

  jobs:
    build_docker:
-     runs-on: ubuntu-latest
+     runs-on: nscloud
      name: Build Docker image

3 And that's it!

There's no step 3!

Now your GitHub Job will be scheduled onto an isolated and ephemeral Namespace Runner.

You can check the Job logs to find out which Namespace Runner processed the GitHub Job. From the below example, we can see that the Runner's name was nsc-runner-5dhbr540ug1gc. So on the Namespace side, the assigned Run ID is 5dhbr540ug1gc.

The job execution will be also available in the Namespace dashboard. The Run ID 5dhbr540ug1gc below links to job started by our example django-app repository.

If you click on it, you can check the Runner's logs and even SSH into the instance itself. This is particularly useful to troubleshoot a problematic CI run. Instead of spending time trying to reproduce the issue and add more logs into your application, you can debug the live GitHub run directly.

You can quickly SSH also through our nsc CLI.

nsc cluster ssh 5dhbr540ug1gc

Start Running on Namespace

Go and give them a try! Our Runners are available in Early Access. You just need to create an account (we only ask for an email!) and you can take advantage of our powerful Runners to improve the efficiency of your CI/CD workflows!