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

571–580 of 584 posts

Re: The Pain That Is GitHub Actions

#571

Post by Arbortheus »

presentation wrote: post #43
ThomasRooney wrote: post #36

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.

Wasn’t part of the problem though that renovate was automatically upgrading people to the compromised hash? Or is that just the fault of people configuring it to be too aggressive with upgrades?

No, someone just impersonated renovate bot and the repo author got tricked

Re: The Pain That Is GitHub Actions

#572

Post by SOLAR_FIELDS »

noplacelikehome wrote: post #527
jimbokun wrote: post #476

Earlier quoted context omitted.

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?

One neat Nix feature is development shells, which let you define isolated shell environments that can be activated by invoking `nix develop` (or via direnv upon entering a directory): devShells.default = pkgs.mkShell { packages = with pkgs; [ opentofu terragrunt ]; }; I can then use these tools inside the devShell from my jobs like so: jobs: terragrunt-plan: runs-on: [self-hosted, Linux, X64] defaults: run: shell: ni…

You can combine this with direnv and auto-activate the nix environment when you `cd` into directories as well. We do this, and just activate the shell in ci environments with a cache. Works great.

Re: The Pain That Is GitHub Actions

#573

Post by pinkgolem »

baq wrote: post #125
pinkgolem wrote: post #84

Earlier quoted context omitted.

There are multiple ways you can do this already from within a script

Ah, the Dropbox comment. > For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

i just told the op that there are multiple ways to archive that without using api keys when in a script.

one of them beeing echoing text to a file. to me, your comparison makes no sense.

Re: The Pain That Is GitHub Actions

#574

Post by tomjakubowski »

xlii wrote: post #103

There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…

I use LLMs for a lot of things these days, but maybe the most important one is as a focus-preserving mechanism for exactly these kinds of middle-ground async tasks that have a feedback loop measured in a handful of minutes.

If the process is longer than a few minutes, I can switch tasks while I wait for it. It's waiting for those things in the 3-10 minute range that is intolerable for me: long enough I will lose focus, not long enough for me to context switch.

Now I can bullshit with the LLM about something related to the task while I wait, which helps me to stay focused on it.

Re: The Pain That Is GitHub Actions

#575

Post by ashishb »

rattray wrote: post #538
ashishb wrote: post #393

Earlier quoted context omitted.

I used to use circle CI earlier. GitHub Actions was an upgrade for me.

why?

GitHub Actions, at least at that time, had a lot more coverage than circle CI.

Anda a lot more flexibility in terms of what can you do.

Re: The Pain That Is GitHub Actions

#576

Post by Marsymars »

anbotero wrote: post #555
Marsymars wrote: post #429

Earlier quoted context omitted.

I have team members who complain that installing and running pre-commit is too much overhead, so instead I see them pushing commit after broken commit that tie up CI resources to fail on the pre-commit workflow. :(

I’ve had people like this. I’m with the other commenter that: Why do they have a say in this? No way I’m letting them decide each day when to format, what style to format to... Meet, discuss, pick a style, enforce formatting, screw you if you don’t follow. I’m also with the other commenter about settings these things at the Editor level, but also at the pre-push level. We benchmark how long it takes to format/lint on…

> Why do they have a say in this?

Because at the institutional level, there isn’t the appropriate will to mandate that devs fix their local environments, and I don’t feel like burning my own political capital on that particular fight.

Agreed on the performance comments.

Re: The Pain That Is GitHub Actions

#577

Post by Marsymars »

tenacious_tuna wrote: post #552
Marsymars wrote: post #429

Earlier quoted context omitted.

I have team members who complain that installing and running pre-commit is too much overhead, so instead I see them pushing commit after broken commit that tie up CI resources to fail on the pre-commit workflow. :(

I'm one of these; I'm loathe to put anything between me and making a commit and most of our linters take several dozen seconds to run. That's unacceptable UX to me; I can disable with `--no-check`, but it's always annoying to remember that when the thing I most want to do is save my working state. I'd rather have linting pushed into the editing process, within my IDE/VS Code/vim plugins, whathaveyou, where it can fee…

Oh, yeah, ours aren’t nearly that bad. Our pre-commit checks are We have a lot of IDE checks, but they’re just warnings when debugging (because devs complained, IMO reasonably, that having them as errors during dev was too inconvenient during development/debugging). CI fails with any warnings, and we have devs who don’t bother to check their IDE warnings before committing and pushing to a PR.

Re: The Pain That Is GitHub Actions

#579

Post by gabyx »

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…

Ohh, @deng, my exact words and you are 100% right. Same experience, same conclusion:

- I would go even further: Do not use bash/python or any duck-typed lang. (only for simple projects, but better just dont get started). - Leverage Nix (!! no its not a joke ecosystem) : devshells or/and build devcontainers out of it. - Treat tooling code, ci code, the exact same as your other code. - Maybe generate the pipeline for your YAML based CI system in code. - If you use a CI system, gitlab, circle etc, use one which does not do stupid things with your containers (like Github: 4 years! old f** up: https://github.com/actions/runner/issues/863#issuecomment-25...)

Thats why we built our own build tool which does that, or at least helps us doing the above things:

https://github.com/sdsc-ordes/quitsh

Re: The Pain That Is GitHub Actions

#580

Post by gabyxgabyx »

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…

Ohh, @deng, my exact words and you are 100% right. Same experience, same conclusion:

- I would go even further: Do not use bash/python or any duck-typed lang. (only for simple projects, but better just dont get started).

- Leverage Nix (!! no its not a joke ecosystem) : devshells or/and build devcontainers out of it.

- Treat tooling code, ci code, the exact same as your other code.

- Maybe generate the pipeline for your YAML based CI system in code.

- If you use a CI system, gitlab, circle etc, use one which does not do stupid things with your containers (like Github: 4 years! old f** up: https://github.com/actions/runner/issues/863#issuecomment-25...). Also one which lets you run dynamically generated pipelines.

Thats why we built our own build tool which does that, or at least helps us doing the above things:

https://github.com/sdsc-ordes/quitsh

Post reply on HN