This is a bit of a rant, but also heads up for anyone who is considering adopting it, and aimed at someone in Microsoft who can influence this project.<p>I am just going to bullet point some of the shortcomings that make it practically unusable for any serious deployment:<p>* You cannot view logs of ongoing jobs. If you navigate to a job view after a task has already started, all you are going to see is a spinner. The job might be stuck in a loop, there might be an error, etc. You won't know until the job ends.<p>* You cannot define which jobs have to _always_ run, i.e. setup and teardown. Suppose you have a matrix of test runners. You need to setup the test environment before jobs start and teardown after they finish. You have the ability to do that on the happy path, but if one of the shards fails and it needs to be retried, there is no way to tell CI to "you must re-run the setup step before retrying this job"<p>* You cannot restrict when CI jobs should run, e.g. Let's say you want to NOT run jobs for Draft PRs. You may try to add `if: github.event.pull_request.draft == false` but that has two serious drawbacks: 1) check will be reported as passed even though it didn't run 2) updating PR from Draft -> Ready does not trigger<p>* You cannot reliably cancel jobs. Sometimes jobs just get stuck and no amount of "Cancel job" requests do anything. The only thing that eventually stops them is the timeout (tip: set timeout for every step exactly for this reason)<p>* There is no built-in mechanism for retries.<p>* You cannot manually retry a particular job until every job in the workflow has finished.<p>This is a non-exhaustive list.
> aimed at someone in Microsoft who can influence this project<p>Hello. I'm the head of product for Actions. Thank you for the comments and we take all customer feedback seriously. I wanted to let you know that we are working on the "you cannot view logs of ongoing jobs" issue. We have also recently shipped a "force cancel" feature (available via API right now until we can build a UI -- <a href="https://github.blog/changelog/2023-09-21-github-actions-force-cancel-workflows/" rel="nofollow noreferrer">https://github.blog/changelog/2023-09-21-github-actions-forc...</a>)
Everyone I know who has spent serious time digging into GH actions has eventually spent an equal amount of time moving off it, because it sucks and is crazy expensive.
> * You cannot view logs of ongoing jobs. If you navigate to a job view after a task has already started, all you are going to see is a spinner. The job might be stuck in a loop, there might be an error, etc. You won't know until the job ends.<p>Don't understand this one. I'm checking this all the time, for instance test runners. Unless you meant older logs from before you opened the page - that one is indeed a bit annoying in some cases<p>I also find it annoying that yaml config is docker-compose like but it's easy to run into random limitations or incompatibilities...
I prefer GitLab CI for raw, get-things-done style configuration. GitHub Actions invents its own world of abstractions that can be fun to play with but that ultimately reduce productivity.
I worked at a place that used GitHub Actions quite recently. I thought it was quite neat and we never had a problem with it, although our CI was fairly simple.<p>I always thought GitHub Actions was intended as simple CI solution for small Github projects. If you need more control and functionality, wouldn't you be better off using dedicated CI system?
We must not be using the same GitHub Actions because most of the list is very much things you can do. I do them almost daily.<p>Further, it sounds like some of your problems are fundamentally incorrect designs in your CI/CD pipe. Not just specific to GitHub Actions.