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

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

531–540 of 584 posts

Re: The Pain That Is GitHub Actions

#531

Post by turboponyy »

jimbokun wrote: post #476
noplacelikehome wrote: post #442

Earlier quoted context omitted.

Nix is awesome for this -- write your entire series of CI tools in she'll or Python and run them locally in the exact same environment as they will run in CI. Add SOPS to bring secrets along for the ride.

Would Nix work well with GitHub Actions? Or is it more of a replacement? How do you automate running tests and deploying to dev on every push, for example?

Yes. GitHub actions can be just a thin wrapper to call any Nix commands that you can run locally.

> How do you automate running tests

You just build the Nix derivation that runs your tests, e.g. `nix build #tests` or `nix flake check` in your workflow file.

> deploying to dev on every push

You can set up a Nix `devShell` as a staging area for any operations you'd need to perform for a deployment. You can use the same devShell both locally and in CI. You'd have to inject any required secrets into the Action environment in your repository settings, still. It doesn't matter what your staging environment is comprised of, Nix can handle it.

Re: The Pain That Is GitHub Actions

#532

Post by DrFalkyn »

Xcelerate wrote: post #209
doix wrote: post #187

Earlier quoted context omitted.

I came from the semiconductor industry, where everything was locally hosted Jenkins + bash scripts. The Jenkins job would just launch the bash script that was stored in perforce(vcs), so all you had to do to run things locally was run the same bash script. When I joined my first web SaaS startup I had a bit of a culture shock. Everything was running on 3rd party services with their own proprietary config/language/etc…

Haha, I had the same experience going from scientific work in grad school to big tech. The phrase “a solution in search of a problem” comes to mind. The additional complexity does create new problems however, which is fine for devops, because now we have a recursive system of ensuring job security. It blows my mind what is involved in creating a simple web app nowadays compared to when I was a kid in the mid-2000s. D…

Creating a simple web app isn’t that hard.

If you want to use a framework The React tutorials from Traversy media are pretty good. You can even do cross platform into mobile app with frameworks like React Native or Flutter if you want iOS/Android native apps.

Vite has been a godsend for React/Vue. It’s no longer the circus it was in the mid 2010s. Google’s monopoly has made things easier for web devs. No more babel or polyfill or createReactApp.

People do still avoid frameworks and use raw HTML/CSS/Javascript. HTMX has made sever fetches a lot easier.

You probably want a decent CSS framework for reponsive design. Everyone used to use minimalist ones like Tailwimd have become more popular.

If you need a backend and want to do something simple you can use BaaS (Backend as a service) platforms like Firebase. Otherwise setting up a NodeJS server with some SQL or KV store like SQLLite or MongoDB isn’t too difficult

CI/CD systems exist to streamline testing and deployment for large complex apps. But for individual hobbyist projects it’s not worth it.

Re: The Pain That Is GitHub Actions

#533

Post by tech_tuna »

0xbadcafebee wrote: post #380

I have used Travis, CircleCI, GitHub Actions, GitLab Pipelines, AWS CodeBuild/CodeDeploy, Bazel, Drone, GoCD, and Jenkins. And I have used GitLab, GitHub, and Bitbucket for hosting VCS files. (I'm the guy who manages this crap for a living, so I have used it all extensively, from startups to enterprises) GitHub Actions is the worst possible CI platform - except for all the others. Every single CI platform has weird l…

It's funny, I've used them all too. . . I like GHA overall but it sure has its quirks.

Anyone who claims that GHA is garbage and any of the others are amazing is either doing something very basic or is crazy, or lying.

At the end of the day, you run shell scripts and commands using a YAML based config language (except for Jenkins). Amazingly, it's hard to build something that does that with the right abstractions and compromises between flexibility and good hygiene.

Re: The Pain That Is GitHub Actions

#534

Post by wvh »

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

I like the premise of something like Dagger, being an Actions CI that can run locally and uses Docker. I don't know if there's an up-and-coming "safe" open-source alternative that does not have that threat of a VC time bomb hanging over it.

Docker and to some extent, however unwieldy, Kubernetes at least allow you to run anywhere, anytime without locking you into a third party.

A "pipeline language" that can run anywhere, even locally, sets up dependency services and initial data, runs tests and avoids YAML overload would be a much needed addition to software engineering.

Re: The Pain That Is GitHub Actions

#536

Post by fireflash38 »

JanMa wrote: post #112
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Whenever possible I now just use GitHub actions as a thin wrapper around a Makefile and this has improved my experience with it a lot. The Makefile takes care of installing all necessary dependencies and runs the relevant build/Test commands. This also enables me to test that stuff locally again without the long feedback loop mentioned in other comments in this thread.

I implemented a thing such that the makefiles locally use the same podman/docker images as the CI/CD uses. Every command looks something like:

target: $(DOCKER_PREFIX) build

When run in gitlab, the DOCKER_PREFIX is a no-op (it's literally empty due to the CI=true var), and the 'build' command (whatever it is) runs in the CI/CD docker image. When run locally, it effectively is a `docker run -v $(pwd):$(pwd) build`.

It's really convenient for ensuring that if it builds locally, it can build in CI/CD.

Re: The Pain That Is GitHub Actions

#539

Post by GabrielTFS »

dmuso wrote: post #506
mike_hearn wrote: post #499

Earlier quoted context omitted.

You just check the "delete files in checkout directory" box in the run screen. Are you thinking of something different? I've never had trouble doing a clean clone.

It’s been a while since I used it but I do remember that it doesn’t do a clean checkout and you can’t force it to. It leaves artifacts on the agent that can interfere with subsequent builds. I assume they do it for speed but it can affect reliability of builds

git clean refuses to work ?

Re: The Pain That Is GitHub Actions

#540

Post by michaelmior »

int_19h wrote: post #484
motorest wrote: post #242

Earlier quoted context omitted.

> I use GH actions. You should treat it like all build systems: let them do what they are good at and nothing else. The rest should be shell scripts or separate docker containers. That's supposedly CICD 101. I don't understand why people in this thread seem to be missing this basic fact and instead they vent about irrelevant things like YAML. You set your pipeline. You provide your own scripts. If a GitHub Action sav…

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

I thin one big benefit of being able to do this is getting more visibility into the pipeline from the GitHub Actions UI/API (including status checks in PR builds). It also helps with reusability. If something is packaged as a GitHub Action, it's much easier to reuse than a shell script written for some other project. GitHub Actions is far from perfect, but I think once you get used to it, it works pretty well.
Post reply on HN