The Pain That Is GitHub Actions

Post by totaldude87 » Fri, Mar 21, 2025, 12:04 AM UTC

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Post by nand_gate » Fri, Mar 21, 2025, 12:05 AM UTC

shykes wrote: post #416

mikepurvis wrote: post #389

Earlier quoted context omitted.

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

Dagger.io does this out of the box: - Everything sandboxed in containers (works the same locally and in CI) - Integrate your build tools by executing them in containers - Send traces, metrics and logs for everything at full resolution, in the OTEL format. Visualize in our proprietary web UI, or in your favorite observability tool

Post by ris » Fri, Mar 21, 2025, 12:21 AM UTC

dzogchen wrote: post #455

ris wrote: post #453

Worst part of GitHub Actions? Its encouragement of the total misuse of containers as what have essentially become installer scripts - complete with all the flakiness you'd imagine. Go look at your workflows and see how much of the runtime is spent running installers upon installers for various languages, package managers and so on. Containers were not supposed to be like this.

Well the default GitHub images come with the kitchen sink, so for most projects you don’t need to install much if anything.

Post by mdaniel » Fri, Mar 21, 2025, 12:43 AM UTC

no_wizard wrote: post #349

baq wrote: post #118

Earlier quoted context omitted.

> I know some people might consider this insanity Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. This is insane. You’re actually introducing much needed sanity into the process by admitting that a real programming language is the tool to use here. I can’t imagine the cognitive dissonance Lisp folks have when dealing with this madness, not be…

I'm shocked there isn't a 'language for config' that hasn't become the de facto standard and its YAML all the way down seemingly. I am with you 100%. It would really benefit from a language that intrinsically understood its being used to control a state machine. As it is, that is what nearly all folks want in practice is a way to run different things based on different states of CI. A lisp DSL would be perfect for th…

Post by zzo38computer » Fri, Mar 21, 2025, 12:58 AM UTC

  on:
    issues:
      types:
        - opened
    pull_request:
      types:
        - opened
  permissions:
    contents: read
    issues: write
    pull-requests: write
  jobs:
    default:
      runs-on: ubuntu-latest
      steps:
        - run: gh issue edit ${{ github.event.issue.number }} --add-assignee ${{ github.repository_owner }}
          env:
            GH_TOKEN: ${{ github.token }}
            GH_REPO: ${{ github.repository }}