This article is more than 1 year old

Deeper dive with GitHub Actions: One config file to rule them all and in the darkness bind them

Code-hosting biz tries out a more automated delivery process

Analysis At its annual developer conference on Tuesday, GitHub unveiled a way to automate software deployment workflows called Actions. It sounds rather underwhelming, given all the different automation tools available, but the executives discussing it brimmed with Apple-level enthusiasm. Sam Lambert, head of platform for GitHub, called it "truly remarkable."

Others from the code hosting biz demonstrated similar excitement. The Register wanted to know whether the condition is contagious, so we talked to some company executives.

GitHub Actions is a way to apply custom logic to software repositories. It's similar in concept to CI/CD but it responds to a broader set of events, presently GitHub webhooks.

"CI/CD is what's today," said Jason Warner, SVP of technology. "We're trying to figure out what's tomorrow."

Actions is intriguing firstly because GitHub is supplying the compute power, via Docker containers, to run Actions automation scripts, and secondly because it makes containers even more useful as a basic building block of computational services and as a medium of exchange.

"At some point, all the major clouds, including us, are just passing containers back and forth," said Warner. "But the magic is not the container to us. The container's just the unit of abstraction. The magic is in the interactions between the containers and the language, the HCL language that we build upon, the workflow language. And then obviously the platform that is underneath it, which is all the different interactions."

GitHub's workflow language, a subset of HCL, will be open source at some point, said Warner.

He describes Actions as an attempt to eliminate some of the ceremony of software deployment – issuing arcane commands and crafting configuration files.

"In a non-ironic way, we say 50 per cent of a developer's time is spent in config files," said Warner. "Each service has its own. Yes, we've introduced another one. It's not 'one to rule them all' but it's 'one to take away a lot of the others,' so you should just be able to point at endpoints. And as more people write Actions, then you don't have to worry about them because that config is taken care of too."

Why something like HCL rather than another configuration language? Kyle Daigle, director of ecosystem engineering, explained, "The files are nicer easier to manage. Indentation isn't a concern." And the format makes it easy to do includes, which import other configuration files.

For example, the file main.workflow might look as follows, if you built it in a text editor rather than the visual editor:

workflow "New workflow" {
  on = "push"
  resolves = ["Hello World"]
}

action "Hello World" {
  uses = "./action-a"
  env = {
    MY_NAME = "Mona"
  }
  args = "\"Hello world, I'm $MY_NAME!\""
}

It would be used in conjunction with a Dockerfile that labels the workflow and a shell script that invokes it. This simple case, a Hello World example, is entirely uninteresting. But Actions can be far more elaborate, like launching an app on five cloud providers at once.

"This is a really great tool for non-compliance based workflows," said Daigle.

GitHub is testing Actions in the hope that enterprise customers will provide input on the kinds of controls they'd need to use it too. An on-premises version is planned, eventually.

GitHub Universe, Sam Lambert

GitHub grabs a piece of the Actions: 'A project that will do for software development what we did for the pull request'

READ MORE

"That might be more complicated for us because that will be you having to manage some of that cluster," said Warner. "But we will provide the primitives that allow that to be the case."

Another goal of the Actions beta test is to learn more about the processing and parallelization needs, since an open source workflow that involves tagging some container images requires different resources than an enterprise workload that deals with dozens of deploying images and apps.

"Right now we're using like a VM-level isolation, said Daigle. "Ultimately a single workflow will live inside of a VM. Then we're going container by container. With parallelization we will split out some of the processing, so that way we're not stuck on a single single server for the entire time."

Daigle sees Actions as a complement to CI/CD and other DevOps tools, a way to fill in the gaps in the software workflow of developers.

"We're just so fundamentally excited about this," Daigle said. "I think because of the open source connection, this is something interesting. I think it's probably our biggest shift since the pull request. I truly believe that." ®

More about

TIP US OFF

Send us news


Other stories you might like