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

111–120 of 238 posts

Re: GitHub Actions could be so much better

#111

Post by EddTheSDET »

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…

How DO you debug your actions? I spend so long in the commit-action-debug-change loop it’s absurd. I agree with your point re: 2 wholeheartedly though, it makes debugging scripts so much easier too. CI should be runnable locally and GitHub actions, while supported with some tooling, still isn’t very easy to work with like that.

Re: GitHub Actions could be so much better

#112

Post by andix »

WirelessGigabit wrote: post #68
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.

All those things the custom build tool would need to handle. It needs more or less the same functionality as GitHub actions and the marketplace. It would also need to integrate with different CI platforms to some extent for reporting and user interactions.

Re: GitHub Actions could be so much better

#113

Post by woodruffw »

nafizh wrote: post #72
woodruffw wrote: post #33

Earlier quoted context omitted.

It's a Jekyll site. I originally built it off of a popular theme (back in 2014 or so), but these days the theme is just a custom thing that I've cobbled together. (So, in a sense, there's no real technology "behind" it. It's just Markdown with a little HTML templating, with Jekyll as the SSG.)

Thanks for the reply. Is the code available by any chance?

Unfortunately not -- it used to be in a public repo, but I also track drafts and other things now that I don't want to be public until they're ready.

I'll see if I can clean it up into a public repository, but no guarantees :-)

Re: GitHub Actions could be so much better

#114

Post by [deleted] »

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…

[deleted]

Re: GitHub Actions could be so much better

#115

Post by andix »

pixl97 wrote: post #85
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…

How does that integrate in with every else's tooling? At least in enterprise there are a ton of things like "SCA, SBOM, Compliance report, etc" that tie in with plugins and such. Also, why would a large commercial CI want to have their environment too open?

They don’t want to have their environments too open, that’s why we are at this point.

Those enterprise tools i know (like sonarqube for example) are mostly cli tools in their core. Can be integrated everywhere.

Re: GitHub Actions could be so much better

#116

Post by duped »

ghayes wrote: post #40
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?

A huge portion of my actions are for things like caching or publishing artifacts, which are unique to actions itself.

Why should caching in the cloud be any different than caching locally?

Re: GitHub Actions could be so much better

#117

Post by rayhu007 »

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…

Totally get what you're saying. I once switched our workflow to trigger on PRs to make testing easier. Now, I'm all about using scripts — they're just simpler to test and fix.

I recommend making these scripts cross-platform for flexibility. Use matrix: and env: to handle it. Go for Perl, JavaScript, or Python over OS shells and put file tasks in scripts to dodge path issues.

I've tried boxing these scripts into steps, but unless they're super generic for everyone, it doesn't seem worth it.

Re: GitHub Actions could be so much better

#118

Post by bdcravens »

layer8 wrote: post #7
darepublic wrote: post #2

I don't see how you love something that makes you jump through these hoops: > In this particular case, it took me 4 separate commits (and 4 failed releases) to debug the various small errors I made: not using ${{ ... }}5 where I needed to, forgetting a needs: relationship, &c

Yeah, I wouldn’t want to use any automation that you can’t also easily and quickly test locally.

Act can do most of it locally

https://github.com/nektos/act

Re: GitHub Actions could be so much better

#119

Post by jjice »

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…

Absolutely agreed. Well said and I'll be stealing this explanation going forward. Hell, just local running with simplicity and ability to test is a massive win of #2, aside from just not dealing with complex YAML.

Re: GitHub Actions could be so much better

#120

Post by baq »

duped wrote: post #116
ghayes wrote: post #40

Earlier quoted context omitted.

A huge portion of my actions are for things like caching or publishing artifacts, which are unique to actions itself.

Why should caching in the cloud be any different than caching locally?

There isn’t any locally in GHA after the runner exits
Post reply on HN