Workflow languages are programming languages. I'd be really interested to know if 1) there's a textual representation of the visual workflow design that you can easily export/import, and 2) the syntax and semantics of the language. I've seen a _lot_ of visual workflow editors which have a tendency towards limited expressiveness; there seems to be a major disconnect between the worlds of workflow authoring and programming.<p>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.<p><a href="https://www.pmkelly.net/publications/wage2008.pdf" rel="nofollow">https://www.pmkelly.net/publications/wage2008.pdf</a><p><a href="https://www.pmkelly.net/publications/thesis.pdf" rel="nofollow">https://www.pmkelly.net/publications/thesis.pdf</a>
Looks like <a href="https://github.com/features/actions" rel="nofollow">https://github.com/features/actions</a> is the GitHub page about this
At first I thought it was just another CI tool exclusive to github.com, but the fact that you can hook up more than just the commit push events makes it interesting for orchestrating a bunch of workflows around issues and pull requests.<p>Also great to see that it supports both UI and code definition.<p>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.
Wow, this could be really useful for my team. We've built a ton of customized workflows on top of github. We use a modified git-flow process, and have bespoke solutions for automatically tagging branches when branches w/ name "hotfix" get into master, when long-living releases get merged, tons of logic for getting commits on a "release-*" branch into dev and other branches.<p>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!
This UI is beautiful. I hope GitLab looks into implementing something similar. Their CI is already so powerful, it would be great to be able to have a UI to build pipelines.
I hope this leads very popular actions being added to GitHub's UI.<p>I'll probably first end up using this for better issue management and triaging:<p>- adding a default set of labels to new issues.<p>- choosing default reviewers<p>- synchronizing labels and GitHub project columns<p>But I really think those things should be built-in. Maybe actions can in part be product research for them.<p>Also, I'd love to see a Node.js serverless function version of this.
Is this made to replace things like Travis and Jenkins? (I have very little experience with them.) The GUI looks very sleek, I'll definitely be checking this out to see how to integrate it into my SE course.
I like that they are using HashiCorp configuration language (1) for the configuration.<p>I have found HCL to be more human-readable than JSON and YAML. But it is plenty strict for use cases like this.<p>1. <a href="https://github.com/hashicorp/hcl" rel="nofollow">https://github.com/hashicorp/hcl</a>
The new UI that Github implemented for it's actions is really slick!<p>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.<p>[0]: <a href="https://www.bpmnquickguide.com/view-bpmn-quick-guide" rel="nofollow">https://www.bpmnquickguide.com/view-bpmn-quick-guide</a>
Here's the official GitHub Actions collection.<p><a href="https://github.com/actions" rel="nofollow">https://github.com/actions</a><p>And for a concrete example, the Docker Action.<p><a href="https://github.com/actions/docker" rel="nofollow">https://github.com/actions/docker</a>
This looks very promising, and I'm eager to try it out for some hobby projects.<p>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.
I'm very hopeful this can replace at least some of our hooks. We've for a fairly a automated process using GitHub labels and it would be great to be able to move some of those off our hook server.
Great news. Also the right way to do CI/CD with each step being a separately configured container with a persistent workspace throughout. Makes it very fast and easy to chain together steps while using small, focused, and updated images.<p>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.
This is very cool. I maintain a GitHub App (pullreminders.com) and I can see Actions helping with setting up additional custom alerts that users sometimes ask for.
If you're as eager as I am to check this out, try this:<p><pre><code> 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".</code></pre>
“Imagine an infinitely more flexible version of shortcut, hosted on GitHub and designed to allow anyone to create an action inside a container to augment and connect their workflow"<p>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?
Interesting that GitHub is continuing to still actively develop independent features after the acquisition. I almost started to say that this seemed like a pushback against Microsoft’s newly-rebranded Azure DevOps before I even remembered...
Wouldn't it make more sense for Microsoft to merge GitHub with their TFS workflow that already has build / test etc. integration to some extent (along with hosting code)? I don't understand this development.