GitHub launches Actions, its workflow automation tool
techcrunch.com
techcrunch.com
I noticed that they provide the ability to specify a Dockerfile which contains the necessary facilities to run arbitrary code. But I can't help but think there has to be a middle ground between the two. I've written about this in the past, arguing that applying concepts from traditional programming language theory (in particular functional programming) to the design of workflow languages can be fruitful.
action "Deploy to Production" {
needs = "Provision Database"
uses = "actions/aws/ec2"
runs = "aws deploy --prod"
}
For example, if you have a graph like the following:
node A
node B
node C
node D
edge B -> A
edge C -> A
edge D -> B
edge D -> C
A (B D) (C D)
Basically, the action syntax they have is like writing an abstract syntax tree where every node explicitly lists its dependencies. An expression is a much more compact form and the subexpressions are implicit in the AST produced by the parser; this is the approach used by most programming languages. But for reasons I still don't fully understand, workflow languages (which I consider to be a specific class of programming language) don't seem to adopt this more compact representation.
We've recently been working on a workflow tool for people significantly less technical than Github's users and we started out with an approach somewhat similar to the one you outline. We developed a compact DSL that maps almost 1-1 with the UI we wanted to build and inferred the dependency graph from the preconditions set and data used in each action. The thinking was that there was no sense in explicit ordering since it could only slow down execution and introduce errors and that allowing preconditions would create a declarative way to ensure "after" behavior when necessary.
But what we found in user testing is that our users kept wanting to manually re-order actions and were really uncomfortable with the system just "figuring out" execution order on its own. We had to introduce the concept of UI-only ordering (the backend still tries as hard as possible to execute in parallel without violating the dependency DAG) to give them the illusion of control.
But our users aren't programmers, so Github might have bit more leeway to push complex topics like these onto users.
For non-programmers, the visual approach is very attractive, and provides an intuitive way to display the workflow in a manner that is easy to make sense of.
For programmers (i.e. pretty much everyone that uses GitHub), I think a more DSL-like approach would be appropriate, though this doesn't preclude a visual editor as an alternative. As gbaygon mentioned, they do have a DSL, but I think the approach is suboptimal.
In a project I'm working on at the moment (which extends the work from my thesis), we're targeting two audiences - programmers write the workflows, but "business" people can see a visualisation. Essentially we take the Scheme code that comprises the workflow and render it as a graph, similar to BPMN. I think that's a nice approach when you have people on staff who have the necessary programming skills and are working alongside non-technical people. But that doesn't apply in every situation, so visual design can be useful when you don't have experienced programmers creating the workflows.
More flexible representations (at the function scale for instance) would probably help even more.
But even then, how often does such a reordering not constitute detail changes as well?
I think visualizations are much more useful for “reading” code, than for writing it. Which is why visual editors are so appealing: they’re showing off the reading aspect.
Im pretty sure something like the grandparent, or that visual-haskell project whose name I cant remember (where code and visualization are directly equivalent) is the way to go: there’s no paradigm shift to be had here.
A few notables:
- Written in Rust. This caused some early struggles, but has been paying dividends ever since we got it working. The thing is rock solid and easily handles tens of thousands automation runs per second. Also, Pest is awesome and writing complex lexer/parser implementation is really easy these days.
- We're currently triggering automations with HTTP calls, but we want to move to primarily triggering with some sort of work queue.
- We didn't consider aggregates in the first iteration of the product and now we're feeling that pain and looking at solutions.
- Tracking the types of all data through every step of the automations was a lot of work to setup, but is hugely valuable. Being able to suggest what values/operations are available to users in the UI as well as doing AOT type checks when saving automations means a lot fewer errors at runtime.
- How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do?
- Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this?
- Do people ever manage to design impossible flows?
- Anything about the use-case you're able to say, for where the tool is needed by users (and not just as an easier way for developers to adjust the system)
> How have users taken to the tool? Have they needed ongoing support, or once trained they understand what to do?
It's been a bit of a struggle. Once people understand how to use the UI, they go to town and get a lot of value out of it. But we've found it's not approachable and basically requires us to teach them how to use it. We're continuing to experiment with it. The good part is that everything we're trying is supported by the underlying DSL and workflow engine and we really haven't had to make more than a couple of tweaks to that.
> Were alternatives considered? Or was the complexity such that a workflow was the only way users could control this?
We looked into off-the-shelf options, but we didn't think they'd give us the level of control we wanted to build a product around it. As mentioned above, the hardest part is the UI, and if we're building this as a product, we need to build that anyways.
> Do people ever manage to design impossible flows?
No, that's impossible through the UI. Since we're tracking the types of all data throughout the execution of the flow, we're able to analyze the flow statically before it's saved to the database and give users an error. But they basically can't even get that because our UI prevents them from choosing illegal values or setting up infinite dependency chains.
> Anything about the use-case you're able to say, for where the tool is needed by users
It's designed to be kinda like Zapier, but for a much more specific audience who are generally less technically adventurous. In talking with these users, many of whom use Zapier, we've identified that they find it difficult to use and not really suited to their use case, so we're hoping that something that's purpose built for that use case will make their lives easier and convince them to switch.
There are other niceties that the Haskell type system gives you by playing with the underlying effects (e.g., forbidding IOs enforces that a same config always gives the same result, using a List allows to cleanly handle heterogeneous-platforms concerns) but these are advanced topics.
Most workflows are a DAG[1], not a graph, this makes them representable as Tuple[List[Step], List[Tuple[Step, List[Step]]]. In other words, (List[Step], Map[Step, Dependencies]), so your example could be
(
(A, B, C, D),
[(A, []),
(B, [A]),
(C, [A]),
(D, [B, C]),
]
)
The expression-y representation doesn't scale well. If you consider that workflows are mostly linear, but have branches, the syntax you provided gets ugly fast.
If you imagine a workflow for a CI like
Lint -> Build -> Test -> Deploy -> Email
\-> Test_Windows -/
Lint (((Build Test) (Build Test_Windows)) (Deploy Email))
[1]: Anything loopy or graph-requiring should be factored out into its own sub-flow implemented in a turing complete construct. A workflow should be a composition of such turing complete sub pieces.
public_key = "${file("${path.root}/../ssh/id_rsa.pub")}"
https://www.terraform.io/docs/configuration/interpolation.ht...
Also great to see that it supports both UI and code definition.
The only big missing feature in my opinion is a shared library support, because it will soon be tedious to copy/paste the same generic docker build commands across repositories.
We ended up building a custom github worker that listens to all of this, but it's opaque and our Bus factor is 1 for that tool. Putting it on Github where anyone can change the rules and see them cleanly is fantastic!
How many devs could win the lottery and retire to a desert island while we still retain working knowledge of it.
Whereas even someone who won the lottery will take a $100k/hr consulting gig, or might take pity on his ex-coworkers and explain his choices in a 1 hour phonecall while sipping margaritas on the beach.
But it’s a reminder that they wouldn’t help if they had financial security.
[0]: https://developer.github.com/actions/creating-workflows/crea...
I believe one thing that cause it is changing a repo from private to public without unchecking Pipelines permission (enabled by default). The new GitLab profile pages looks absolutely gorgeous, but I suspect many will be turned off by the highly visible 'build: failed' icons next to the repos, even if those repos contain nothing but a JSON file.. I personally had to resort to deleting the repo and creating a new one to get rid of it. And on that note, clicking on the '/users/username/projects?limit=10&page=2' next button results in the Overview tab turning blank.
The profile page, however, doesn't seem to update. My guess is that it's a caching problem. I've logged https://gitlab.com/gitlab-org/gitlab-ce/issues/52780 for this.
Having something digital to substitute the whiteboard would be fantastic. Not just for designing the pipeline, but also for seeing the results of an actual run of the pipeline.
Implementations of workflow languages optimised for compute performance (e.g. using JIT compilation) do exist, but are not widely used outside of situations where the workflow combines both compute-intensive work and coordination of external tasks.
The Actions UI is going to be huge for user adoption.
I can't say how many commits I had of various .gitlab-ci.yml files with just tiny changes in each one.
People get caught up in the on-size-fits-all mentality. If you are a 20 man start-up it’s stupid to make 3 separate solutions that all compete. When you employ north of a hundred thousand people, it’s less of an issue.
It's not hard to get right, it's not difficult to get wrong either-everyone has their spin on messaging and that kind of choice is perfectly fine. We don't need one to rule them all, at least IMO.
But goodness gracious Google just seems to have NO clue what they're doing with messaging. Which is frustrating because in the sliver of time they got it right, they got it right (that time when Hangouts was actually kind of great, it was well integrated, and looked like Google was actually trying to make it better? Member those days?) and then-as expected-they stripped the car for parts and we ended up with two communications (Duo and Allo) platforms that really should have been one feature-rich solution.
Or they’ll make it a separately charged feature once they evaluate demand and usage in the beta, but AFAIK that would be new for GitHub.
Not new- GitHub's hosted Git LFS product costs $5/month per 50gb bandwidth/storage, after a 1gb free tier [1].
[1] https://help.github.com/articles/about-storage-and-bandwidth...
Edit: Seems like workflows can only be created in private repos [1],
> You can only create workflows in private repositories.
but actions can be public [2].
> To share GitHub Actions with the GitHub community, your repository must be public.
[1] https://developer.github.com/actions/creating-workflows/crea...
[2] https://developer.github.com/actions/creating-github-actions...
https://developer.github.com/actions/creating-workflows/crea...
> You can only create workflows in private repositories
Maybe they need a new category of paid but still public.
Nope, it's about money.
They've hosted Github pages for free for quite some time... though this may use far more resources.
I'll probably first end up using this for better issue management and triaging:
- adding a default set of labels to new issues.
- choosing default reviewers
- synchronizing labels and GitHub project columns
But I really think those things should be built-in. Maybe actions can in part be product research for them.
Also, I'd love to see a Node.js serverless function version of this.
Now, I'd like to be wrong. But I doubt a UI can get close to plain text for this kind of thing, it's just very difficult for software to translate boxes into code.
Until then, there's a reason our tooling is text-based to this day.
And also to create a shared library of actions. Perhaps they will eventually go for creating a common standard for workflow actions across platforms.
I have found HCL to be more human-readable than JSON and YAML. But it is plenty strict for use cases like this.
As far as implementation I'm starting to wonder if anyone actually uses BPMN[0]...It might be nice if we had a standardizable way to do these orchestrations, and I thought BPMN was it.
And for a concrete example, the Docker Action.
One thing I haven't found skimming the docs is a manual approval gate, which would be very useful for projects that don't have full automated test coverage (so, nearly all of them) before a production deployment.
That seems a little backwards for a small web app.
There's only a few providers that seem to get this right so it's nice to see included in github. I was just talking to the Azure DevOps people about this kind of functionality so it seems like GH is and will continue to be run independently of MS/Azure.
The closest that I found is [1]:
> Actions are defined in a Docker container. Actions run in an environment where they have access to the code in your repository, variables you define, and secrets you make available to the action.
I get the impression from that and [2] that it's only private containers on GitHub servers for now.
Another interesting observation from the docs [3] currently:
> You can only create workflows in private repositories.
I imagine that's a temporary constraint for now?
Edit: Found more info on the runtime environment [4].
[1]: https://help.github.com/articles/about-github-actions/
[2]: https://help.github.com/articles/creating-a-workflow-with-gi...
[3]: https://developer.github.com/actions/creating-workflows/crea...
[4]: https://developer.github.com/actions/creating-github-actions...
Seems like this would be pretty easy to abuse, and I was able to sign up with my free account. We'll have to see how long this lasts...
1. Go here as a logged in user: https://github.com/actions/docker/blob/master/.github/main.workflow
2. Click Edit on the file (top right corner, pencil icon)
3. Edit existing workflow, or click "Create a new workflow".XML
> or Gradle?
Apache Groovy
Err... so like code? If he phrases it like that, does that mean that the target audience isnt developers? I mean why else go with such an analogy?
Even then we shouldn't be particularly worried. Vendor lock-in is an unusual problem; deciding to change vendor is rare and if there's a good reason to do it then it's worth spending resources. The only time it's a real problem is when you absolutely have to change and you don't have the resources to do the necessary work.