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

141–150 of 238 posts

Re: GitHub Actions could be so much better

#141

Post by pests »

giobox wrote: post #95
dmart wrote: post #92

Earlier quoted context omitted.

Granted, it's not HTML, but you can append Markdown output directly to $GITHUB_STEP_SUMMARY without dealing with artifact uploads etc.

Thanks, I'm aware of this option too, but if you say have an HTML report with the results of 200 tests, no one has time to write some logic to parse the results to a markdown summary frankly. Just give me the link! Similar too if the reporting captures video/screenshots of a given bug - the original report UI is far easier to deal with. Many test frameworks already natively put out an HTML report UI etc, it's just ha…

> an HTML report with the results of 200 tests, no one has time to write some logic to parse the results to a markdown summary frankly.

Not sure how GHA treats it, but markdown is a subset of HTML so by default all HTML pages are valid Markdown documents. No conversion required.

Re: GitHub Actions could be so much better

#142

Post by plonk »

The best approach is to develop completely local build scripts and add a few options to plug GitHub Actions' exclusive features into them. Make a build script that can take a cache folder's path as argument. Make it take a test report output path as another argument. etc.

So your GHA workflow is: set up secrets (AWS and co.), set up Python, download cache to path X if possible, run the build in X and send reports to Y, publish reports in Y. And put as much work as possible inside the build script. We have a whole Python project for that.

This is truly painless after the first development effort.

Re: GitHub Actions could be so much better

#143

Post by neuromanser »

garciasn wrote: post #6
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

We use Github Actions and we just don't have any issues with it outside the first time we set it up for each repo. Then we make 100s of commits a week and it does its thing and our work goes live a few seconds later. That's why I love it. Could things be better? Of course; that's how software is--and this should resonate with most folks on this site. But just because some product isn't infallible doesn't mean we can'…

> we just don't have any issues with it outside the first time we set it up for each repo

But that's exactly what a lot of commenters complain about.

Re: GitHub Actions could be so much better

#144

Post by MoreQARespect »

EddTheSDET wrote: post #111
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.

Using the same commit-push-debug loop you do. It just isnt painful if I do 2.

Re: GitHub Actions could be so much better

#145

Post by solatic »

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 repository to represent setup of the CI environment, and have both (a) the CI rebuild the container images when the image would change, pausing workflows depending on that image until the image is rebuilt, (b) not attempting to rebuild the image when its contents did not change, and immediately running workflows inside that image, including all dependencies already installed.

No, in GitHub Actions, you will attempt to repopulate from cache on every single run. Of course, sometimes the cache isn't found, particularly because there's a 5 GB cache size limit (which cannot be enlarged, not even for payment) which cycles out FIFO. So if you go over the 5 GB cache, you might as well not have one.

I deeply miss Concourse. Too bad Pivotal dismantled the team and it barely gets even maintenance work. Parallel tasks. Custom pipeline triggers. SSH into the CI environment to debug. Run one-off tasks in CI without needing to set up a pipeline. Transfer directory contents from one job to another without needing to create artifacts (which cost money to store if you're not careful about how long they should stick around for).

GitHub Actions is a bastardized toy CI/CD system that only got popular because GitHub make it as simple as uploading a file to .github/workflows in any repository - no additional signup, no in-house ops required, everything you could want is just there. So let's be very clear about what GitHub Actions is good and what it's bad at - it's good at getting people to sign up, but it's not nearly powerful enough to be the "best" system once you start to outgrow the early features.

Re: GitHub Actions could be so much better

#146

Post by gravlaks »

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…

https://dagger.io/

may be an alternative. You can run it in GitHub actions somehow as well.

Re: GitHub Actions could be so much better

#147

Post by bob1029 »

My experience with GitHub Actions is mostly managed by way of certain Azure Portal interactions these days.

When I create a new Function app, it gives me the opportunity to enable GitHub integration. The experience for this is flawless, IMO. You provide your GH credentials, select the org/repo/branch, and then it will create the workflow file for you and push it automatically. It will also update the secrets in your repository settings to match what Azure expects on its end for deployment.

By the time you get to look at your GitHub repo, the action is already running and will 100% complete successfully if you followed a standard/default project structure. The automatically-generated workflow files aren't perfect, but they're so close that it becomes trivial to tweak for additional build args or project arrangements. Just getting the secrets & related boilerplate configured makes the difference between me doing it right now vs maybe never. The consequence of always having proper CI/CD from day zero, even for the most trivial projects, seems profound to me.

There exist some really happy paths now wrt GH actions, but you gotta be willing to get pretty hammered on the Microsoft koolaid to explore them.

Re: GitHub Actions could be so much better

#148

Post by avtar »

mason55 wrote: post #131
avtar wrote: post #63

Earlier quoted context omitted.

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

Well, that's why the word "official" is in there. Obviously you could mock up the entire github actions scaffolding locally and have it inject environment variables and support all the actions and everything, but keeping that up to date will be a nightmare if you're doing it on your own. Obviously you could put the whole CI/CD into a bash script and not use any features or functionality provided by github actions but…

I didn't mention it in my reply but I was referring to the complaint in the article that the author wants to be able to debug locally without having to push changes to GitHub first. The top comment by MoreQARespect and others highlight the benefits of scripting as much as possible so that processes like builds and cutting releases can be run and tested locally.

> Obviously you could mock up the entire github actions scaffolding locally

Not sure if anyone's advocating for implementing GA entirely. You can at least automate project-specific bits as much as possible using scripts, and then have the CI environment use the same automation. That allows for more local debugging than overusing GA.

Re: GitHub Actions could be so much better

#149

Post by chubot »

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…

Exactly, I showed here how we just write plain shell scripts. It gives you "PHP-like productivity", iterating 50 times a minute. Not one iteration every 5 minutes or 50 minutes.

https://lobste.rs/s/veoan6/github_actions_could_be_so_much_b...

Also, seamlessly interleaving shell and declarative JSON-like data -- without YAML -- is a main point of http://www.oilshell.org, and Hay

Hay Ain't YAML - https://www.oilshell.org/release/0.18.0/doc/hay.html

Re: GitHub Actions could be so much better

#150

Post by wry_discontent »

umvi wrote: post #90
riquito wrote: post #75

Earlier quoted context omitted.

I agree overall, but you oversimplify the issue a bit. > can I push this YAML complexity into a script? - what language is the script written in? - will developers use the same language for all those scripts? - does it need dependencies? - where are we going to host scripts used by multiple github actions? - if we ended up putting those scripts in repositories, how do we update the actions once we release new version…

Default to bash. If the task is too complex for bash, then use python or node. Most of these scripts aren't going to change very often once stable.

Default to babashka.
Post reply on HN