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

551–560 of 584 posts

Re: The Pain That Is GitHub Actions

#551

Post by kbolino »

motorest wrote: post #481
kbolino wrote: post #264

Earlier quoted context omitted.

When it gets realistic, with conditions, variable substitutions, etc., it ends up being 20 steps in a language that isn't shell but is calling shell over and over again, and can't be run outside of CI. Whereas, if you just wrote one shell script, it could've done all of those things in one language and been runnable locally too.

> When it gets realistic, with conditions, variable substitutions, etc., What exactly do you find hard in writing your own scripts with a scripting language? Surely you are not a software developer who feels conditionals and variable substitutions are hard. > it ends up being 20 steps in a language that isn't shell but is calling shell over and over again, and can't be run outside of CI. Why are you writing your CICD…

This is not about YAML in some general or abstract sense, it is about a YAML-based domain-specific language. If you think this is just about YAML, you are hyper-focused on the wrong detail.

In order to use this domain-specific language properly, you first must learn it, and learning YAML is but a small part of that. Moreover, it is not immediately obvious that, once you know it, you actually want to avoid it. But you can't avoid it entirely, because it is the core language of the CI/CD platform. And you can't know how to avoid it effectively until you have spent some time just using it directly. Simplicity comes from tearing away what is unnecessary, but to discern necessary from unnecessary requires judgment gained by experience. There is no world in which this knowledge transfers immediately, frictionlessly, and losslessly.

Furthermore, there is a lot that GitHub (replace with platform of choice) could have done to make this better. They largely have no incentive to do so, because platform lock-in isn't a bad thing to the platform owner, and it's a nontrivial amount of work on their part, just as it is a nontrivial amount of work on your part to learn and use their platform in a way that doesn't lock you into it.

Re: The Pain That Is GitHub Actions

#552

Post by tenacious_tuna »

Marsymars wrote: post #429
stared wrote: post #390

Earlier quoted context omitted.

I do such things with pre-commit. Doing it in CI sounds like making things more complicated by resetting to remote branches after pushing commits. And, in the worst case, something that actually brakes code that works locally.

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 feedback-loop with my actual writing process and not just be some ancillary command I run with lots of output I never read.

Re: The Pain That Is GitHub Actions

#553

Post by kbolino »

bastardoperator wrote: post #549
kbolino wrote: post #548

Earlier quoted context omitted.

> But GitHub recommends that Where?

Here: https://docs.github.com/en/actions/writing-workflows/choosin...

Nothing in that document states anything remotely like the antecedent of "that", which was:

> don't have anything particularly interesting in the .yml file, just the bare minimum plus some small number of uncomplicated script invocations to install dependencies and actually do the build

It is a very basic "how to" with no recommendations.

Moreover, they directly illustrate a bad practice:

      - name: Run the scripts
        run: |
          ./my-script.sh
          ./my-other-script.sh
This is not running two scripts, this is running a shell command that invokes two scripts, and has no error handling if the first one fails. If that's the behavior you want, fine, but then put it in one shell script, not two. What am I supposed to do with this locally? If the first shell script fails, do I need to fix it, or do I just proceed on to the second one?

Re: The Pain That Is GitHub Actions

#554

Post by duijf »

ruuda wrote: post #98

To make sure that you can test CI locally, the best way I've found so far is to make sure the checks can run with Nix, and then keep the CI config itself as simple as possible and just call Nix. As for reducing boilerplate in the CI configs, GitHub Actions is a programming language with support for functions! It's just that function calls can only appear in very limited places in the program (only inside `steps`), an…

> It's just that function calls can only appear in very limited places in the program (only inside `steps`), and to define a function, you have to create a Git repository.

FYI there is also `on: workflow_call` which you can use to define reusable jobs. You don't have to create a new repository for these

https://docs.github.com/en/actions/writing-workflows/workflo...

Re: The Pain That Is GitHub Actions

#555

Post by anbotero »

Marsymars wrote: post #429
stared wrote: post #390

Earlier quoted context omitted.

I do such things with pre-commit. Doing it in CI sounds like making things more complicated by resetting to remote branches after pushing commits. And, in the worst case, something that actually brakes code that works locally.

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 only changed files, usually no more than a second, maybe two, but I admit for some languages this may take more. An editor with a language server properly setup would have helped you find issues earlier.

We also have reports for our CI pipeline linters, so if we see more than 1 report there, we sent a message to the team: It means someone didn’t setup their editors nor their git hooks.

If the checks take more than a second, yeah, probably pre-commit is not the place/moment. Reliability is important, but so is user experience. I had companies where they ran the unit test suite at the pre-commit level, alright? And that is NOT fine. While it sounds like it’ll find issues earlier, it’ll screw your developer time if they have to wait seconds/minutes each time they fix a comma.

Re: The Pain That Is GitHub Actions

#556

Post by bastardoperator »

kbolino wrote: post #553
bastardoperator wrote: post #549

Earlier quoted context omitted.

Here: https://docs.github.com/en/actions/writing-workflows/choosin...

Nothing in that document states anything remotely like the antecedent of "that", which was: > don't have anything particularly interesting in the .yml file, just the bare minimum plus some small number of uncomplicated script invocations to install dependencies and actually do the build It is a very basic "how to" with no recommendations. Moreover, they directly illustrate a bad practice: - name: Run the scripts run:…

It does even if you don't like it. You can put your logic in a script and execute that. That is what is being conveyed here in a blistering simple fashion. You could also make it one script, or two or three, you could even break those out into steps.

This is invoking a shell and that's how shells typically work, one command at a time. Would it make you feel better if they added && or used a step like they also recommend to split these out? You can put the error handling in your script if need be, that's on you or the reader, most CI agents only understand true/false or in this case $?.

Nobody said they want that behavior, they're showing you the behavior. They actually show you the best practice behavior first, not sure if you didn't read that or are purposely omitting it. In fact, the portion you highlight, is talking about permissions, not making suggestions.

      - name: Run a script
        run: ./my-script.sh
      - name: Run another script
        run: ./my-other-script.sh

Re: The Pain That Is GitHub Actions

#557

Post by kbolino »

bastardoperator wrote: post #556
kbolino wrote: post #553

Earlier quoted context omitted.

Nothing in that document states anything remotely like the antecedent of "that", which was: > don't have anything particularly interesting in the .yml file, just the bare minimum plus some small number of uncomplicated script invocations to install dependencies and actually do the build It is a very basic "how to" with no recommendations. Moreover, they directly illustrate a bad practice: - name: Run the scripts run:…

It does even if you don't like it. You can put your logic in a script and execute that. That is what is being conveyed here in a blistering simple fashion. You could also make it one script, or two or three, you could even break those out into steps. This is invoking a shell and that's how shells typically work, one command at a time. Would it make you feel better if they added && or used a step like they also recomm…

This is not a discussion about what's possible, it's a discussion about what's best. You can write your own opinion here, and it seems like we're in violent agreement, but that doesn't make our opinion GitHub's opinion.

That page is just one small part of a much larger reference document, and it doesn't seem opinionated at all to me. Plus there are dozens of other examples elsewhere in the same reference that are not simple invocations of one shell script and nowhere are you admonished not to do things that way.

Re: The Pain That Is GitHub Actions

#558

Post by mdaniel »

never_inline wrote: post #514
mqus wrote: post #465

Earlier quoted context omitted.

include:component is usually what you want now, you can version your components (Semver), add a nice readme and it is somewhat integrated in the gitlab UI. Not sure about the other include: ones, but you can also define inputs for component and use them at arbitrary places like template variables. Since the integration is done statically, it means gitlab can provide you a view of the pipeline script _after_ all compo…

Doesn't include:component still require all your shell script to be written inside YAML? or is there a way to move the logic to a, for instance, .sh file and call it from YAML?

I realize this may be splitting hairs, but pedantically there's nothing in GitLab CI's model that requires shell; it is, as best I can tell, 100% docker image based. The most common setup is to use "script:" (or its "before_script:" and "after_script:" friends) but if you wanted to write your pipeline job in brainfuck, you could have your job be { image: example.com/brainfuckery:1, script: "" } and no shell required[1]

1: although TIL that the "script:" field itself is actually required in GLCI https://docs.gitlab.com/ci/yaml/#script

Re: The Pain That Is GitHub Actions

#559

Post by bastardoperator »

kbolino wrote: post #557
bastardoperator wrote: post #556

Earlier quoted context omitted.

It does even if you don't like it. You can put your logic in a script and execute that. That is what is being conveyed here in a blistering simple fashion. You could also make it one script, or two or three, you could even break those out into steps. This is invoking a shell and that's how shells typically work, one command at a time. Would it make you feel better if they added && or used a step like they also recomm…

This is not a discussion about what's possible, it's a discussion about what's best. You can write your own opinion here, and it seems like we're in violent agreement, but that doesn't make our opinion GitHub's opinion. That page is just one small part of a much larger reference document, and it doesn't seem opinionated at all to me. Plus there are dozens of other examples elsewhere in the same reference that are not…

And they show those patterns first. You had to take an example that is clearly about script permissions and misrepresent it. Yeah, it's not opinionated, it's fact. That's how it works...

Re: The Pain That Is GitHub Actions

#560

Post by quantadev »

neuroelectron wrote: post #516
kelseydh wrote: post #132

Earlier quoted context omitted.

With widespread dependencies like AWS or Github, if they go down.. you benefit from everybody else also going down. Downtime of that kind means a lot of media coverage and an easier/more understanding conversation with your affected customers. The worst kind of downtime is when you go down but nobody else has.

Is your argument, literally, "everybody else is doing it?"

I think it was all about "having excuses" for one's bad decisions, to avoid taking responsibility. lol.
Post reply on HN