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

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 …

  1. JohnFen Silver badge

    Doing it wrong

    "In a non-ironic way, we say 50 per cent of a developer's time is spent in config files,"

    It is? Wow, I and everyone I've ever worked with must be doing it wrong, because I would have put that percentage at less than 1.

    1. Ken Hagan Gold badge

      Re: Doing it wrong

      This quote should have been at the start of the article. It would have saved me valuable time that I could have spent in a config file.

  2. SVV Silver badge

    Eliminates arcane commands and configuration files

    With the HelloWorld example provided here, it appears to do this by using arcane commands in a configuration file.

  3. Charlie Clark Silver badge

    Copying Bitbucket again?

    Pipelines has been around for a couple of years now.

  4. bombastic bob Silver badge

    Microsoft's influence

    I smell that (see topic).

    What I see: Yet another overly-complex market-speak technology being touted as the 'new shiny' that everyone MUST embrace, which really targets a tiny percentage of customers/end-users, and probably complicates more things than it de-complicates in the process, and will likely be abandoned later down the road for YET ANOTHER new, shiny. But other git services won't have "this", so it attempts to keep people from migrating elsewhere...

    Yep. Smells like Micro-shaft's influence allright. I'm predictably underwhelmed.

    Just how much 'automation' do we need from git repos anyway? I've seen one attempt at integrating the git repo stuff into 'things' before, and it resulted in a virtually unusable [because it was SO pig-slow] google doc spreadsheet that was trying to track hours to issues in a private github repo. I've seen better performance on a swap-bound windows '95 system with 4Mb. Example: waiting 30 seconds to a MINUTE for a change I typed in to 'take' so I could move the cursor (due to the formulas copy/pasta'd throughout the spreadsheet). Yeah, it was THAT bad. Do we need MORE things like that? I suspect NOT.

    (I tracked hours manually and it was a lot easier, and probably a lot faster, by storing a draft e-mail on an IMAP server that had the hours and issues in it, as simple plain text)

  5. Hstubbe

    I find this kind off stuff works well in gitlab (of the self-hosted variant). I'm sure the github execs think this is the best thing since sliced silicium wafers, but to me they're just trying to catch up with the competition.

  6. Claptrap314 Bronze badge


    You know, you could just go with Chef. Or Terraform. Or probably Puppet. (I've not seen the last one.)

    The syntax is HORRIBLE. And these are NOT config files. They don't even dare to call them that. These are DSLs for arbitrary code execution wrapped & hidden so as to make it hard (or impossible) to test. Chef's saving grace is that the testing ethic is so strong the in the ruby community that Chef kitchen was out within months.


    If your computational needs are Turing complete, you need a Turning complete facility to manage them. Sticking some arcane DSL wrapper over the problem is ALWAYS going to fail as system grows.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019