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

61–70 of 238 posts

Re: GitHub Actions could be so much better

#61

Post by ZeWaka »

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…

> GH Actions is basically a re-brand of Microsoft's "Azure Pipelines"

Probably even moreso than most people think - a large portion of the AzDo team got moved over after the acquisition to work on GitHub Actions/Projects.

Re: GitHub Actions could be so much better

#62

Post by giobox »

joshstrange wrote: post #32

I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…

> I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks.

One tool is to use draft PRs for this - you can run changes to your action YAML from the draft PR. When you are happy just squash the commits as you see fit on a "real" PR to merge the changes in without the mess.

I've found draft PRs for debugging/developing GH action logic to be pretty reasonable.

Re: GitHub Actions could be so much better

#63

Post by avtar »

nthState wrote: post #14

Most of my problems would vanish if there was an official way to run workflows locally, something like: shell: run_workflow name=MyJob in=MyWorkflow.yml params={}

I guess you have to ask yourself what's in MyWorkflow.yml that can't be in a script and run locally?

Re: GitHub Actions could be so much better

#64

Post by andix »

joshstrange wrote: post #32

I couldn't agree more with the pain of debugging a GH Actions run. The /only/ tool you have is the ability to re-run with debug on. That's it. I have so many "trash" commits trying to fix or debug a pipeline and so much of it's just throwing stuff at the wall to see if it sticks. Very basic things, like having reusable logic, is needlessly complex or poorly documented. Once I figured out how to do it it was fairly ea…

If I'm fixing CI I always put it on a feature branch and do a squash merge once I'm done. Because it's never just one quick fix, it's always 3-10 commits.

Re: GitHub Actions could be so much better

#65

Post by MoreQARespect »

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

No, you're right it's not necessarily a good idea to be anal about this rule. E.g. If an action is simple to use and already built I use it - I won't necessarily try to reimplement e.g. upload artifacts step in code.

Another thing I noticed is that if you do 1 sophisticated features like build caching and parallelization often becomes completely impractical whereas if you default to 2 you can probably do it with only a moderate amount of commit-push-debug.

Re: GitHub Actions could be so much better

#66

Post by wbond »

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 have a few open source projects that have lasted for 10+ years, and I can’t agree more with approach #2.

Ideally you want your scripting to handle of the weird gotchas of different versions of host OSes, etc. Granted my work is cross-platform so it is compounded.

So far I’ve found relying on extensive custom tooling has allowed me to handle transitions from local, to Travis, to AppVeyor, to CircleCI and now also GitHub Actions.

You really want your CI config to specify the host platform and possibly set some env vars. Then it should invoke a single CI wrapper script. Ideally this can also be run locally.

Re: GitHub Actions could be so much better

#67

Post by gchamonlive »

I am thinking about porting my ci/cd pipelines from Jenkins to GitHub actions to leverage autoscaling self-hosted runners, which I don't think there is an exact equivalent for Jenkins nodes, at least not one that is already implemented where I work.

The pipelines though, are all configured using ansible. Applying the same principle I did to Jenkins, using it strictly for execution automation, logs, permission and the likes, and leaving the heavy lifting to a more trusty tool, I think I can avoid both major vendor lock-in and idiosyncrasies and nonsenses from the language.

It boggles my mind how unrefined the GitHub actions flow is. It doesn't offer a good experience by a long shot.

Re: GitHub Actions could be so much better

#68

Post by WirelessGigabit »

andix wrote: post #59

I'm really not sure if we are using CI correctly. Sometime i think all those CI Templates should be replaced by just one executable that does everything, like a modern alternative to Makefiles (and there are a lot of build tools). So the CI pipeline would only call the build tool, like "./build containers push-to-registry release:1.0.0 run-tests" Those scripts can be tested and debugged everywhere. Also migrating to…

While this is totally possible you lose a lot of the things that make GitHub Actions nice. Nice logs, annotations, individual steps that went wrong. Being able to see the status at a glance. Seeing 10 steps where 1 fails and 13 pass is nice.

Re: GitHub Actions could be so much better

#69

Post by dcow »

ZeWaka wrote: post #58
baq wrote: post #41

Earlier quoted context omitted.

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…

> with no persistent storage There's https://github.com/actions/cache though?

They're saying that unless you use actions, you don't get the cohesive cache and artifacts support. That replicating that in the cloud or locally is a PITA. Thus people are using the GH actions vendor specific tooling in that way.
Post reply on HN