Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions could be so much better

blog.yossarian.net

Post reply on HN
Print view View original

41–50 of 238 posts

Re: GitHub Actions could be so much better

#41

Post by baq »

taeric wrote: post #35
candiddevmike wrote: post #26

Earlier quoted context omitted.

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`.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

It's the cloud. Runners are ephemeral (pretend, but still) with no persistent storage. This makes you either rebuild everything in every release stage (bad) or put artifacts in s3 or whatever (also bad) - this is especially painful for intermediate artifacts like dependency bundle caches etc.

As much as I like make it just doesn't work with the typical cloud stateless by default configs. If it works for you, your project is small enough and try to keep it this way.

Re: GitHub Actions could be so much better

#42

Post by mock-possum »

whalesalad wrote: post #30
rurp wrote: post #27

It's hard for me to articulate exactly why but I really dislike the information layout in GH Actions. Compared to other CI/CD tools, it's harder to debug problems or get a sense of the state of a pipeline. Part of the problem is the number of clicks it takes to look at various step logs. Some of the controls are unintuitive, but maybe that's just me.

This could be said for a lot of GitHub. The fact that you need to open a disclosure menu to edit a PR is wild.

Their comment system just doesn’t feel right compared to Bitbucket’s either - I think it’s the distinction between comments that are part of a review, versus comments that are ‘just’ comments

Re: GitHub Actions could be so much better

#43

Post by woodruffw »

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…

This is a great perspective, and one I agree with -- many of the woes associated with GitHub Actions can be eliminated by treating it just as a task substrate, and not trying to program in YAML.

At the same time, I've found that it often isn't sufficient to push everything into a proper programming language: I do sometimes (even frequently) need to use vendor-specific functionality in GHA, mark dependencies between jobs, invoke REST APIs that are already well abstracted as actions, etc. Re-implementing those things in a programming language of my choice is possible, but doesn't break the vendor dependency and is (IME) still brittle.

Essentially: the vendor lock-in value proposition for GHA is very, very strong. Convincing people that they should take option (2) means making a stronger value proposition, which is pretty hard!

Re: GitHub Actions could be so much better

#44

Post by woodruffw »

Pxtl wrote: post #39
woodruffw wrote: post #36

Earlier quoted context omitted.

> 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. I was under the impression (which might be wrong!) that GH…

They share a lot of code. My understanding is that it was an MS project first, but I might have that backwards. > GitHub Workflows execute on runners. The runner code is essentially a fork of the Azure Pipelines code, so it's very similar. It's also cross-platform and you can also use hosted or self-hosted runners. https://learn.microsoft.com/en-us/dotnet/architecture/devops...

Thanks for the link -- I knew that GHA workflow runs ran on Azure, but I didn't know the workflow runner itself was a fork of Azure's runner/instrumentor. That's interesting context!

Re: GitHub Actions could be so much better

#45

Post by woodruffw »

simse wrote: post #21

A linter can catch some obvious errors: https://github.com/rhysd/actionlint . But yes, I agree, it's not a fun debugging experience.

Yep, actionlint is great! I've used it successfully both to lint my own workflows, and to lint third-party workflows for (basic) security issues.

Unfortunately, it can't lint actions themselves, only workflows that call actions[1]. This is a substantial deficiency, especially for users (like me) who write and maintain a decent number of actions.

[1]: https://github.com/rhysd/actionlint/issues/46

Re: GitHub Actions could be so much better

#46

Post by he0001 »

We recently converted from Jenkins to GitHub Actions (complete rewrite) build pipeline. Jenkins had its issues and warts, but holy Beelzebub what a monster GitHub Actions is. It pure downright evil and creates all sort of headaches. Opaque, zero clues on what broke. Glacial slow even if you throw the biggest instance at it. It’s all enterprise and 1000s of repositories big company.

I’m spending more time finding bugs in the build pipeline than the time I spend doing other things. And it’s all GitHub actions fault. I hate it with a passion.

Re: GitHub Actions could be so much better

#47

Post by ramraj07 »

taeric wrote: post #35
candiddevmike wrote: post #26

Earlier quoted context omitted.

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`.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

All the linting checks and end to end tests I don’t want to bother setting up locally for every repo I touch.

Re: GitHub Actions could be so much better

#48

Post by pjc50 »

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…

I've reached the same conclusion with Jenkins. It also helps if you ever have to port between CI systems.

A CI "special" language is almost by definition something that can't be run locally, which is really inconvenient for debugging.

Re: GitHub Actions could be so much better

#49

Post by taeric »

baq wrote: post #41
taeric wrote: post #35

Earlier quoted context omitted.

I'm actually confused and scared on how often this isn't the case? What are people doing in their actions that isn't easily doable locally?

It's the cloud. Runners are ephemeral (pretend, but still) with no persistent storage. This makes you either rebuild everything in every release stage (bad) or put artifacts in s3 or whatever (also bad) - this is especially painful for intermediate artifacts like dependency bundle caches etc. As much as I like make it just doesn't work with the typical cloud stateless by default configs. If it works for you, your pro…

Rebuilding at every stage shouldn't be too bad, with pinned dependencies. I can see problems with it, of course. That said, using a private code publishing location seems the correct path? That isn't too difficult to setup, is it?

That said, I'm still not clear on what difficulties folks are worried about. I'm also not clear I care on the mess of commits getting things working. The initial commits of getting anything working are almost always a mess. Such that worrying about that seems excessive.

Re: GitHub Actions could be so much better

#50

Post by evntdrvn »

woodruffw wrote: post #36
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…

> 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. I was under the impression (which might be wrong!) that GH…

the original GHA implementation was shitcanned
Post reply on HN