GitHub Actions could be so much better • Hacker News Board

Re: GitHub Actions could be so much better

#191

Post by Huggernaut » Sat, Sep 23, 2023, 5:14 AM UTC

speed_spread wrote: post #187

solatic wrote: post #145

GitHub Actions is a horrible CI/CD system. You cannot run steps in parallel on the same VM; container-based workloads are a second-class citizen. The first problem means that setting up local credentials and other environment dependencies cannot be parallelized (I'm looking at you, google-github-actions/setup-gcloud, with your 1m+ runtime... grrr), the second makes it quite difficult to put a Dockerfile in a reposito…

Concourse rocks. I didn't know the team had been dismantled, this sucks. Zito's communication style was the best.

Vito is at dagger.io now so hopefully we can expect some good stuff in the CI space there.

Re: GitHub Actions could be so much better

#192

Post by Huggernaut » Sat, Sep 23, 2023, 5:22 AM UTC

solatic wrote: post #145

GitHub Actions is a horrible CI/CD system. You cannot run steps in parallel on the same VM; container-based workloads are a second-class citizen. The first problem means that setting up local credentials and other environment dependencies cannot be parallelized (I'm looking at you, google-github-actions/setup-gcloud, with your 1m+ runtime... grrr), the second makes it quite difficult to put a Dockerfile in a reposito…

Less Pivotal and more VMWare post acquisition dismantling I'd say. There was a lot of love internally for Concourse (I left before the acquisition though).

SSH debugging and one off tasks absolutely dreamy.

Re: GitHub Actions could be so much better

#193

Post by totetsu » Sat, Sep 23, 2023, 5:26 AM UTC

no_wizard wrote: post #173

davidmurdoch wrote: post #166

Earlier quoted context omitted.

My GH Actions debugging usually devolves into `git commit -m "wtfqwehsjsidbfjdi"`

you could always do git commit -m "" --allow-empty

git commit -m "--allow-empty"

Re: GitHub Actions could be so much better

#194

Post by mook » Sat, Sep 23, 2023, 6:30 AM UTC

EddTheSDET wrote: post #190

somehnguy wrote: post #125

Earlier quoted context omitted.

Act works pretty well to debug actions locally. It isn't perfect, but I find it handles about 90% of the write-test-repeat loop and therefore saves my teammates from dozens of tiny test PRs.

> saves my teammates from dozens of tiny test PRs May have misread this but you know you can push to one branch and then run the action against it? Would reduce PRs if you're doing that to then check the action in master. You have to add a workflow_dispatch to the action: https://docs.github.com/en/actions/using-workflows/manually-...

And if you're working on workflows that need to be in PRs, you can make a PR from your fork _to_ your fork.

Re: GitHub Actions could be so much better

#195

Post by diarrhea » Sat, Sep 23, 2023, 6:33 AM UTC

no_wizard wrote: post #173

davidmurdoch wrote: post #166

Earlier quoted context omitted.

My GH Actions debugging usually devolves into `git commit -m "wtfqwehsjsidbfjdi"`

you could always do git commit -m "" --allow-empty

You can even allow empty messages.

Re: GitHub Actions could be so much better

#196

Post by pplonski86 » Sat, Sep 23, 2023, 6:37 AM UTC

MoreQARespect wrote: post #24

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

YAML is perfect for simple scenarios. But users produces with it really complex use cases.

Is it possible to write Python package that based on YAML specification produces Python API? User will code in Python and YAML will be the output.

I was working on YAML syntax for creating UI. I converted it to Python API and Im happy. For exmple, dynamic widgets in YAML were hard, in Python they are strightforward.

Re: GitHub Actions could be so much better

#197

Post by lpapez » Sat, Sep 23, 2023, 7:08 AM UTC

lenkite wrote: post #176

I wish Github Actions were Lua instead of YAML. One could use a restricted environment populated with predefined functions, a restricted set of modules and all the advantages of syntax checking and language help.

Congratulations, you just reinvented Jenkins but using Lua instead of Groovy.

Re: GitHub Actions could be so much better

#198

Post by mook » Sat, Sep 23, 2023, 7:11 AM UTC

secret-noun wrote: post #135

lambda_garden wrote: post #89

Earlier quoted context omitted.

Since some action depend on the branch / tag you are on this is not always possible.

Indeed. I have sometimes made release workflows, hardcoded to the main branch. You don't want to experiment too much on main because it dirties your commit history with 20 "Fix typo"-esque commits. Or, if you try to emulate the main branch with a fake main branch (so you can squash it later), you're still going to have some test commits when do the find-replace back to main. Neither are great.

Sometimes forking and using the main branch on the fork (or tags and releases) can help. And if you're on a team, nobody else needs to be aware of the noise that is you throwing trivial changes at the wall.

It gets painful if there are things you've only got on the main repo (e.g. custom runners, credentials, etc.) though.

Re: GitHub Actions could be so much better

#199

Post by Pxtl » Sat, Sep 23, 2023, 7:14 AM UTC

jahsome wrote: post #168

Pxtl wrote: post #18

I mean GH Actions is basically a re-brand of Microsoft's "Azure Pipelines". As somebody who used all previous incarnations of TFS/VSTS/AzDO build and release pipelines: they are not good at this . This is not a team with a record of success. That Azure Pipelines is moderately usable only happened because they failed literally every other approach they tried. There was a project to allow you to run the pipelines local…

You had me up til that last paragraph. Call me crazy but xml just hurts my eyes. I'll always take a nicely formatted yaml doc with all the pains that come with it over the horrors of angle brackets and camel case.

XML syntax is bad, but yaml doesn't have a proper blessed batteries-included built-in schema language afaik. A well formed XML with an xmlns will have validation and autocomplete in a good editor thanks to this. JSON can do it too. Never seen it done with yaml.

It's a pretty big frustration in a language that is so slow to test -- commit push run wait find the error oh I made a typo. Better code-time validation fixes this but the tooling for that in yaml is weak.

Re: GitHub Actions could be so much better

#200

Post by thiht » Sat, Sep 23, 2023, 7:21 AM UTC

candiddevmike wrote: post #26

tao_at_garden wrote: post #8

The git commit, push, wait loop is terrible UX. Users deserve portable pipelines that run anywhere, including their local machines. I understand Act [1] goes some way to solving this headache but it's by and large not a true representation. There are many pipelines you can't run locally, because they're production, for example, but there's no reason why we can't capture these workflows to run them locally at less-cri…

If folks just had actions target make or bash scripts instead of turning actions into bash scripts none of this would be an issue. Your CI/CD and your devs should all use the same targets/commands like `make release`.

Well… yeah?

My GitHub actions workflow consist of calls to make lint, make test, make build, etc. Everything is useable in local.

There’s just some specificities when it comes to boot the dependencies (I use a compose file in local and GitHub action services in CI, I have caching in CI, etc.) but all the flows use make.

This is not a technical problem, you’re just doing it wrong if you don’t have a Makefile or equivalent.