7 ms·

Automating a Software Company with GitHub Actions

247 points by mariusandra 5y ago

ryanmarsh 5y ago
LOL a software company is more, so much more, than CI. I thought I was going to read something novel about using GitHub actions for tracking sales leads or customer success or something.
- spzb 5y ago
  This does seem to be a pretty bog-standard usage of a CI/CD tool. I must be missing something.
- k__ 5y ago
  Seems like the article and also comments here imply just that. GitHub Actions aren't focused on CI, so they are much more useful.
  - clipradiowallet 5y ago
    > GitHub Actions aren't focused on CI, so they are much more useful. Compared to what? ie.. Jenkins, CircleCI, Gitlab's CI/CD...none of them are "focused on CI", and can more or less do anything you want them to. I'm not trying to be argumentative, but I'm having trouble thinking of a CI/CD system that is more(or less) focused on CI than Github actions is - do you have some examples?
    - yjftsjthsd-h 5y ago
      I'm not familiar with GH, but gitlab is definitely focused on building/running things from a commit in a repo to the point of making it awkward to do ad hoc actions or tasks not clearly tied to one repo. You can do it, but it's harder and has weird restrictions.
      - dnsmichi 5y ago
        We started using Pipeline schedules in my past job to regularly trigger pipelines to e.g. rebuild Docker build images, clear caches and other sorts where you normally need shell access to a cronjob. https://docs.gitlab.com/ee/ci/pipelines/schedules.html https://docs.gitlab.com/ee/ci/pipelines/schedules.html Similarly, you can trigger pipelines from various angles https://docs.gitlab.com/ee/ci/triggers/ https://docs.gitlab.com/ee/ci/triggers/ using the API. If you are looking to combine it with events on-demand, the webhooks may come in handy. https://docs.gitlab.com/ee/user/project/integrations/webhooks.html https://docs.gitlab.com/ee/user/project/integrations/webhook... Agreed, some adhoc actions are project specific, though you can programmatically walk through them in API client code, for example searching for a group and triggering all project's pipelines. https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html https://python-gitlab.readthedocs.io/en/stable/gl_objects/gr... https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html#triggers https://python-gitlab.readthedocs.io/en/stable/gl_objects/pi...
danpalmer 5y ago
One of the things I like about Actions is how much it's focused on automation rather than CI. The pain points I've had with Circle/GitLab/Travis have often boiled down to the fact that they are often very specifically about _testing software_, not _automating processes_, and not even _deploying software_. On that last one, there's a potential bug in the deployment pipeline here – deploys could run simultaneously or some bad luck on runner speed could even see an older version of the code go out after a newer version. Combined with the automated database migrations this could be quite a big problem! Actions thankfully solved this recently with the `concurrency` key that lets you form a serial queue by a given key such as the branch name.
- verdverm 5y ago
  I'm not sure the concurrency key can solve the issue of old code after new code, in the general case. What happens if there are conflicting migrations on two "parallel" branches? What happens in you bad luck situation when commits are pushed in rapid succession on the same branch?
  - danpalmer 5y ago
    With the concurrency key at the top level, actions run it commit order. As for running migrations on the same database from multiple branches, not a good idea. Probably best to decide on the branch that is the release branch (maybe main/master) and only deploy from that.
- sytse 5y ago
  In GitLab you can limit concurrency by using a resource group https://about.gitlab.com/blog/2020/01/21/introducing-resource-groups/ https://about.gitlab.com/blog/2020/01/21/introducing-resourc... Does that address your need? Edit with more context: We use CI for deploying to GitLab.com and use resource_group to prevent multiple jobs from running concurrently. What we lack is the ability to prevent multiple pipelines from running concurrently (resource_group is at the job level). It looks like concurrency for actions https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency https://docs.github.com/en/actions/reference/workflow-syntax... can work on groups which is a bit nicer. There is some discussion about making this better for GitLab in https://gitlab.com/gitlab-org/gitlab/-/issues/217522 https://gitlab.com/gitlab-org/gitlab/-/issues/217522
reidjs 5y ago
GitHub Actions are such a great tool, I use them to schedule tweets for me.
- steeleduncan 5y ago
  Interesting, do you have a link to an example action for this?
  - reidjs 5y ago
    This should get you started :D let me know if you need help setting it up https://github.com/reidjs/markdown-tweet-scheduler https://github.com/reidjs/markdown-tweet-scheduler
    - steeleduncan 5y ago
      Thanks for that, that looks great. I've been looking for a way to post regularly without actually having to do it. tweetdeck is nice, but its still more hassle than filling a folder with markdowns.
  - deleted 5y ago
    [deleted]
- joehx2 5y ago
  me too! and Facebook posts, too.
BugsJustFindMe 5y ago
I love GH actions, but they're still a bit too sharp-edged for my taste. Like...the last time I checked, workflows had no runtime macro for limiting execution to the default branch except explicitly by a specific name, and the closest you could get to generically checking "whatever the default branch is called right now" was either a template workflow that would set some static text for the name at creation that breaks if the default branch name is subsequently changed or a song and dance querying the API and setting an environment variable inside one of the workflow steps and then gating all subsequent steps on the result. This was a long time after they introduced editable default branch names and seems like such an obvious oversight. Then there are weird quirks like the subshell file system permissions block that requires using sudo if you want to move files around within your repo clone from inside an invoked shell script.
- mtalantikite 5y ago
  One relatively simple thing I'd love is the ability to re-run a job where it fails, which is something other CI systems have. On a current project we have some flaky Cypress tests and it sucks to have to re-run the entire workflow from the start when one of the last steps of the job fails. I'm definitely not the only one wanting this [1]. They also offer triggering workflows with 'workflow_run' based on other workflows, but that only happens on the default main branch. We auto build testing environments on each PR and I'd love to be able to have better workflow management based on branches. [1] https://github.com/actions/runner/issues/432 https://github.com/actions/runner/issues/432
  - simonw 5y ago
    Looks like someone has built a reusable action for retries: https://github.com/marketplace/actions/retry-step https://github.com/marketplace/actions/retry-step
duped 5y ago
I just want to be able to write all my workflow code as typescript (including the config - no YAML, for the love of god, no more YAML!) and run it locally with a debugger attached. It's cost me hundreds to thousands of dollars to implement nontrivial workflows because of how the YAML is parsed (for example, empty strings when using a secret that has been renamed or removed) and the lack of introspection or debuggability when something goes wrong. It's gotten to the point where new any new workflows I write are thin wrappers around a single script and I don't import any actions besides actions/checkout (even that has been bug prone, historically). All that said, it's not like other platforms are better. But they certainly are cheaper and don't have dumb breakages when you need cross platform builds (has upload-artifact been fixed for executables on MacOS yet?)
- i_s 5y ago
  Yea, making it so statements are composing via YAML was a very poor choice. One case I had was needing to change my actions so that steps D, E, and F could be retried together. What is the github YAML specification for decrementing a 'tries_remaining' variable, then going back to a previous step? I couldn't find it, so ended up just having to rewrite the action so that most of the steps are now in one bash script. Not being able to execute it locally has also wasted a lot of time, and people needing to make 50+ changes to the master branch until they get it right.
  - pc86 5y ago
    This might be an unpopular opinion but bundling CI/CD logic with the application code has been a huge blunder IME. If you're adding CI/CD for the first time to a brownfield project you're looking at dozens of minor YAML tweaks to master directly (or a bunch of rubber-stamped PRs). Why can't I have a separate interface where I just say "build this Github project, and put the content on this on-prem server/kube cluster/VM/whatever."
    - simonw 5y ago
      If I'm doing something complex with GitHub Actions I like to work in a branch, iterate with a bunch of messy tweak commits and then squash-merge into main once I've got it working exactly right. Another trick that works well is putting GitHub Actions in an entirely separate repository. There's nothing to stop actions in one repo from checking out code from another - I use that trick quite frequently. You do have to jump through a few extra hoops to set it up so that code in your actions repo starts running automatically on commits to your main repo, but you can do that with a small action in the main repo that triggers a build in the actions repo.
bklyn11201 5y ago
Can anyone point me to an example of a Github action resulting in standing up a fully working backend with a resolvable DNS entry for manual pull request testing?
- mulmboy 5y ago
  I can't point you to an existing one. However I'm confident I could put this together in a day. Do you think it would be difficult? Github actions can be boiled down to running shell commands (with a bunch of other handy features), so it's quite versatile. At times it does require you to make workflows which are a bit convoluted but all in all I think it's pretty good.
c17r 5y ago
I did a triple-take "...at PostHog we've been avid users of GitHub since its early ARPANET days."
- OJFord 5y ago
  Yeah I don't get that, is it a joke? Pun? Some meaning that isn't how I'm (or your first two takes) reading it? Even git's early days were well after the last ARPANET days. Edit: I suppose they just mean 'since time immemorial', but in internets. Perhaps I'm just tired/'whooshed' but I think that was more confusing than they were going for!
  - Twixes 5y ago
    Hey, I'm the author of the article, I sneakily put that bit in just to see who notices the absurd of it. ;) But sorry for the resulting triple-takes!
    - cutemonster 5y ago
      > I sneakily put that bit in just to see who notices the absurd of it. ;) This give me ideas :-)
jbergstroem 5y ago
I noticed their hadolint action and couldn't help but think it falls a bit short in terms of flexibility and output. I wrote an action to improve these type of use cases that can be found here: https://github.com/jbergstroem/hadolint-gh-action https://github.com/jbergstroem/hadolint-gh-action
crooked-v 5y ago
At my company, the biggest pain points we've run into with GitHub Actions are all centered around the many lacking aspects of permission handling. - You can't pull in private dependencies published from other repos (for example, packages published on repo A used as a dependency on repo B) without using a private access token. - You can't use git pulls from other repos (for example, repo B using `orgname/repoA#123456` as a dependency in package.json) without using a private access token, and it's a pain in the ass to make it work across workflow steps. - You can't allow Dependabot to run as a trusted user, which makes it impossible to actually use any of the workarounds for the above issues with it. - You can't create PRs to publish changes across repos (such as automatically keeping some set of files in sync) without using a private access token. There are other complications, but those are the biggest ones.
- Tainnor 5y ago
  The dependabot issue is insane, and the whole way this issue arose (it used to work before this limitation was introduced) indicates that the security team and the dependabot team at GitHub just didn't talk to each other. (There's a workaround for the dependabot issue though, use pull_request_target instead and explicitly check out the sha of the branch. Then the run can access the secrets.) I would also add "you can't rerun single jobs" and "actions can't call other actions" to the list of grievances.
atonse 5y ago
GitHub actions is really making me want to move our company back there from GitLab. Does GitLab have a response planned?
valenterry 5y ago
As long as automation solutions (such as all ci-tooling) uses yaml to define logic instead of a proper programming language (or at least configuration language like dhall), I will try to stay away from them as much as possible.
AliBoukeroui 5y ago
That's cool :)
cube00 5y ago
I'm always hesitant to lock into solutions like these because they may not always be offered on the same terms. For example, recently when they had to reduce access to GitHub Actions because miners were abusing it. Where as my local configuration management (Ansible, Puppet etc.) script can always run anywhere and I can even run on my own build VM if I need too.

247 points by mariusandra 5y ago

LOL a software company is more, so much more, than CI. I thought I was going to read something novel about using GitHub actions for tracking sales leads or customer success or something.

spzb 5y ago
This does seem to be a pretty bog-standard usage of a CI/CD tool. I must be missing something.
k__ 5y ago
Seems like the article and also comments here imply just that. GitHub Actions aren't focused on CI, so they are much more useful.
- clipradiowallet 5y ago
  > GitHub Actions aren't focused on CI, so they are much more useful. Compared to what? ie.. Jenkins, CircleCI, Gitlab's CI/CD...none of them are "focused on CI", and can more or less do anything you want them to. I'm not trying to be argumentative, but I'm having trouble thinking of a CI/CD system that is more(or less) focused on CI than Github actions is - do you have some examples?
  - yjftsjthsd-h 5y ago
    I'm not familiar with GH, but gitlab is definitely focused on building/running things from a commit in a repo to the point of making it awkward to do ad hoc actions or tasks not clearly tied to one repo. You can do it, but it's harder and has weird restrictions.
    - dnsmichi 5y ago
      We started using Pipeline schedules in my past job to regularly trigger pipelines to e.g. rebuild Docker build images, clear caches and other sorts where you normally need shell access to a cronjob. https://docs.gitlab.com/ee/ci/pipelines/schedules.html https://docs.gitlab.com/ee/ci/pipelines/schedules.html Similarly, you can trigger pipelines from various angles https://docs.gitlab.com/ee/ci/triggers/ https://docs.gitlab.com/ee/ci/triggers/ using the API. If you are looking to combine it with events on-demand, the webhooks may come in handy. https://docs.gitlab.com/ee/user/project/integrations/webhooks.html https://docs.gitlab.com/ee/user/project/integrations/webhook... Agreed, some adhoc actions are project specific, though you can programmatically walk through them in API client code, for example searching for a group and triggering all project's pipelines. https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html https://python-gitlab.readthedocs.io/en/stable/gl_objects/gr... https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html#triggers https://python-gitlab.readthedocs.io/en/stable/gl_objects/pi...

danpalmer 5y ago

One of the things I like about Actions is how much it's focused on automation rather than CI. The pain points I've had with Circle/GitLab/Travis have often boiled down to the fact that they are often very specifically about _testing software_, not _automating processes_, and not even _deploying software_. On that last one, there's a potential bug in the deployment pipeline here – deploys could run simultaneously or some bad luck on runner speed could even see an older version of the code go out after a newer version. Combined with the automated database migrations this could be quite a big problem! Actions thankfully solved this recently with the `concurrency` key that lets you form a serial queue by a given key such as the branch name.

verdverm 5y ago
I'm not sure the concurrency key can solve the issue of old code after new code, in the general case. What happens if there are conflicting migrations on two "parallel" branches? What happens in you bad luck situation when commits are pushed in rapid succession on the same branch?
- danpalmer 5y ago
  With the concurrency key at the top level, actions run it commit order. As for running migrations on the same database from multiple branches, not a good idea. Probably best to decide on the branch that is the release branch (maybe main/master) and only deploy from that.
sytse 5y ago
In GitLab you can limit concurrency by using a resource group https://about.gitlab.com/blog/2020/01/21/introducing-resource-groups/ https://about.gitlab.com/blog/2020/01/21/introducing-resourc... Does that address your need? Edit with more context: We use CI for deploying to GitLab.com and use resource_group to prevent multiple jobs from running concurrently. What we lack is the ability to prevent multiple pipelines from running concurrently (resource_group is at the job level). It looks like concurrency for actions https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency https://docs.github.com/en/actions/reference/workflow-syntax... can work on groups which is a bit nicer. There is some discussion about making this better for GitLab in https://gitlab.com/gitlab-org/gitlab/-/issues/217522 https://gitlab.com/gitlab-org/gitlab/-/issues/217522

reidjs 5y ago

GitHub Actions are such a great tool, I use them to schedule tweets for me.

steeleduncan 5y ago
Interesting, do you have a link to an example action for this?
- reidjs 5y ago
  This should get you started :D let me know if you need help setting it up https://github.com/reidjs/markdown-tweet-scheduler https://github.com/reidjs/markdown-tweet-scheduler
  - steeleduncan 5y ago
    Thanks for that, that looks great. I've been looking for a way to post regularly without actually having to do it. tweetdeck is nice, but its still more hassle than filling a folder with markdowns.
- deleted 5y ago
  [deleted]
joehx2 5y ago
me too! and Facebook posts, too.

BugsJustFindMe 5y ago

I love GH actions, but they're still a bit too sharp-edged for my taste. Like...the last time I checked, workflows had no runtime macro for limiting execution to the default branch except explicitly by a specific name, and the closest you could get to generically checking "whatever the default branch is called right now" was either a template workflow that would set some static text for the name at creation that breaks if the default branch name is subsequently changed or a song and dance querying the API and setting an environment variable inside one of the workflow steps and then gating all subsequent steps on the result. This was a long time after they introduced editable default branch names and seems like such an obvious oversight. Then there are weird quirks like the subshell file system permissions block that requires using sudo if you want to move files around within your repo clone from inside an invoked shell script.

mtalantikite 5y ago
One relatively simple thing I'd love is the ability to re-run a job where it fails, which is something other CI systems have. On a current project we have some flaky Cypress tests and it sucks to have to re-run the entire workflow from the start when one of the last steps of the job fails. I'm definitely not the only one wanting this [1]. They also offer triggering workflows with 'workflow_run' based on other workflows, but that only happens on the default main branch. We auto build testing environments on each PR and I'd love to be able to have better workflow management based on branches. [1] https://github.com/actions/runner/issues/432 https://github.com/actions/runner/issues/432
- simonw 5y ago
  Looks like someone has built a reusable action for retries: https://github.com/marketplace/actions/retry-step https://github.com/marketplace/actions/retry-step

duped 5y ago

I just want to be able to write all my workflow code as typescript (including the config - no YAML, for the love of god, no more YAML!) and run it locally with a debugger attached. It's cost me hundreds to thousands of dollars to implement nontrivial workflows because of how the YAML is parsed (for example, empty strings when using a secret that has been renamed or removed) and the lack of introspection or debuggability when something goes wrong. It's gotten to the point where new any new workflows I write are thin wrappers around a single script and I don't import any actions besides actions/checkout (even that has been bug prone, historically). All that said, it's not like other platforms are better. But they certainly are cheaper and don't have dumb breakages when you need cross platform builds (has upload-artifact been fixed for executables on MacOS yet?)

i_s 5y ago
Yea, making it so statements are composing via YAML was a very poor choice. One case I had was needing to change my actions so that steps D, E, and F could be retried together. What is the github YAML specification for decrementing a 'tries_remaining' variable, then going back to a previous step? I couldn't find it, so ended up just having to rewrite the action so that most of the steps are now in one bash script. Not being able to execute it locally has also wasted a lot of time, and people needing to make 50+ changes to the master branch until they get it right.
- pc86 5y ago
  This might be an unpopular opinion but bundling CI/CD logic with the application code has been a huge blunder IME. If you're adding CI/CD for the first time to a brownfield project you're looking at dozens of minor YAML tweaks to master directly (or a bunch of rubber-stamped PRs). Why can't I have a separate interface where I just say "build this Github project, and put the content on this on-prem server/kube cluster/VM/whatever."
  - simonw 5y ago
    If I'm doing something complex with GitHub Actions I like to work in a branch, iterate with a bunch of messy tweak commits and then squash-merge into main once I've got it working exactly right. Another trick that works well is putting GitHub Actions in an entirely separate repository. There's nothing to stop actions in one repo from checking out code from another - I use that trick quite frequently. You do have to jump through a few extra hoops to set it up so that code in your actions repo starts running automatically on commits to your main repo, but you can do that with a small action in the main repo that triggers a build in the actions repo.

bklyn11201 5y ago

Can anyone point me to an example of a Github action resulting in standing up a fully working backend with a resolvable DNS entry for manual pull request testing?

mulmboy 5y ago
I can't point you to an existing one. However I'm confident I could put this together in a day. Do you think it would be difficult? Github actions can be boiled down to running shell commands (with a bunch of other handy features), so it's quite versatile. At times it does require you to make workflows which are a bit convoluted but all in all I think it's pretty good.

c17r 5y ago

I did a triple-take "...at PostHog we've been avid users of GitHub since its early ARPANET days."

OJFord 5y ago
Yeah I don't get that, is it a joke? Pun? Some meaning that isn't how I'm (or your first two takes) reading it? Even git's early days were well after the last ARPANET days. Edit: I suppose they just mean 'since time immemorial', but in internets. Perhaps I'm just tired/'whooshed' but I think that was more confusing than they were going for!
- Twixes 5y ago
  Hey, I'm the author of the article, I sneakily put that bit in just to see who notices the absurd of it. ;) But sorry for the resulting triple-takes!
  - cutemonster 5y ago
    > I sneakily put that bit in just to see who notices the absurd of it. ;) This give me ideas :-)

jbergstroem 5y ago

I noticed their hadolint action and couldn't help but think it falls a bit short in terms of flexibility and output. I wrote an action to improve these type of use cases that can be found here: https://github.com/jbergstroem/hadolint-gh-action https://github.com/jbergstroem/hadolint-gh-action

crooked-v 5y ago

At my company, the biggest pain points we've run into with GitHub Actions are all centered around the many lacking aspects of permission handling. - You can't pull in private dependencies published from other repos (for example, packages published on repo A used as a dependency on repo B) without using a private access token. - You can't use git pulls from other repos (for example, repo B using `orgname/repoA#123456` as a dependency in package.json) without using a private access token, and it's a pain in the ass to make it work across workflow steps. - You can't allow Dependabot to run as a trusted user, which makes it impossible to actually use any of the workarounds for the above issues with it. - You can't create PRs to publish changes across repos (such as automatically keeping some set of files in sync) without using a private access token. There are other complications, but those are the biggest ones.

Tainnor 5y ago
The dependabot issue is insane, and the whole way this issue arose (it used to work before this limitation was introduced) indicates that the security team and the dependabot team at GitHub just didn't talk to each other. (There's a workaround for the dependabot issue though, use pull_request_target instead and explicitly check out the sha of the branch. Then the run can access the secrets.) I would also add "you can't rerun single jobs" and "actions can't call other actions" to the list of grievances.

atonse 5y ago

GitHub actions is really making me want to move our company back there from GitLab. Does GitLab have a response planned?

valenterry 5y ago

As long as automation solutions (such as all ci-tooling) uses yaml to define logic instead of a proper programming language (or at least configuration language like dhall), I will try to stay away from them as much as possible.

AliBoukeroui 5y ago

That's cool :)

cube00 5y ago

I'm always hesitant to lock into solutions like these because they may not always be offered on the same terms. For example, recently when they had to reduce access to GitHub Actions because miners were abusing it. Where as my local configuration management (Ansible, Puppet etc.) script can always run anywhere and I can even run on my own build VM if I need too.