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

461–470 of 584 posts

Re: The Pain That Is GitHub Actions

#462

Post by jkarni »

nand_gate wrote: post #451
mikepurvis wrote: post #389

Earlier quoted context omitted.

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

Why would you need extra visualisation anyway, tooling like Nix is already what you see is what you get!

It’s still helpful to eg fold different phases in Nix, and different derivation output.

I work on garnix.io, which is exactly a Nix-based CI alternative for GitHub, and we had to build a lot of these small things to make the experience better.

Re: The Pain That Is GitHub Actions

#463

Post by fiddlerwoaroof »

mikepurvis wrote: post #398
steeleduncan wrote: post #392

Earlier quoted context omitted.

> Write as much CI logic as possible in your own code Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop. Setting up a nix build cache also means that any artefact built by your CI is instantly available…

Absolutely. Being able to have a single `nix build` line that gets all the way from source to your final asset (iso, ova, container image, whatever) with everything being aggressively cached all the way along is a game changer. I think it's worth the activation energy for a lot more organizations than realize it.

Imo, the “activation energy” is a lot lower than it appears too. The determinate systems nix installer solves a lot of the local development issues and it’s fairly easy, as a first pass, to write a simple derivation that just copies your current build process and uses nix for dependencies.

Re: The Pain That Is GitHub Actions

#464

Post by fiddlerwoaroof »

akanapuli wrote: post #319
JanMa wrote: post #112

Earlier quoted context omitted.

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 dont quite understand the benefit. How does running commands from the Makefile differ from running commands directly on the runner ? What benefit does Makefile brings here ?

If you have your CI runner use the same commands as local dev, CI basically becomes an integration test for the dev workflow. This also solves the “broken setup instructions” problem.

Re: The Pain That Is GitHub Actions

#465

Post by mqus »

wwarek wrote: post #47
jicea wrote: post #33

Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant: https://docs.gitlab.com/ci/yaml/#includeremote

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 components were included, but without actually running it.

We are using this and it is so nice to set up. I have a lot of gripes with other gitlab features (e.g. environments, esp. protected ones and their package registry) but this is one they nailed so far.

Re: The Pain That Is GitHub Actions

#467

Post by bluGill »

HeavyStorm wrote: post #427
bluGill wrote: post #341

Earlier quoted context omitted.

I would feel that way but I've had the misfortune to work with a wide open ci system where any developer could make thanges and one guy did. The locked down system prevents me form some changes I want but in return my builds don't suddenly start failing because some ci option was turned on for everyone.

I totally prefer to have the ci break from time to time and be able to fix it than having the risk of it being broken and having no way of fixing it

The people who admin our CI system do a good job so it doesn't break, (well it does all the time, but onnetwork type errors not configuration - that is IT's fault not their fault.)

The thing I want to change are things that I do in the build system so that it is checked in and previous versions when we need to build them (we are embedded where field failure is expensive so there are typically branches for the current release, next release, and head). This also means anything that can fail on CI can fail on my local system (unless it depends on something like the number of cores on the machine running the build).

While the details can be slightly different, how we have CI is how it should be. most developers should have better things to do than worry about how to configure CI.

Re: The Pain That Is GitHub Actions

#468

Post by sontek »

I'm surprised that they were already using earthly and decided not to continue using it inside github actions. That is my favorite pattern so that what github actions is doing is the same as what I'd do locally. No `act` necessary:

      - name: Install Earthly
        if: steps.check_changes.outputs.relevant_changes == 'true'
        uses: earthly/actions-setup@v1
        with:
          version: v${{ env.EARTHLY }}

      - name: Run tests and generate coverage summary
        if: steps.check_changes.outputs.relevant_changes == 'true'
        run: cd src/webapp && earthly --build-arg GO_VERSION=${{ env.GOLANG }} +coverage-summary
Post reply on HN