218
Fixing CI (feddit.it)
submitted 10 months ago by to c/programmer_humor@programming.dev
26 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 73 points 10 months ago* (15 children)

Ah yes, I hate the fact that you cannot run GitHub Actions workflows locally in order to debug them.

  • permalink
  • fedilink
  • source
  • hideshow 15 child comments
    •
  • [–] 25 points 10 months ago (3 children)

    Kind of can but its easier for me to spam commits to main instead. https://github.com/nektos/act

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 10 months ago

    I've spent so much time trying to get act working well enough that it's easier to use than pushing to remote but it gets really difficult when you involve things like AWS services (especially when the tokens to push to ECR aren't available to me as a lowly dev). Localstack can help but the container registry functionality is locked behind the paid version

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 10 months ago

    The DX of this project is not ideal at all. Like, they are using a different image than GitHub provided, so you get different errors when you deploy… which defeats the entire purpose! That’s if you figured out how to run it locally in the first place after weird errors.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 18 points 10 months ago (6 children)

    Circleci, Travis, and gitlab all allow you to ssh into the box you are trying your scripts on and fix it there. Much easier and takes a lot less time. Github actions have an unofficial way of doing it and is....not the best. Actions is actually one of the worst CIs I'm my experience.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 10 months ago (3 children)

    For gitlab this is only correct with a shell executor which is to be avoided in the general case in favor of a docker or k8s executor for isolation&repeatability.

    Those you can actually run locally with gitlab-runner, but then you won't have all your gitlab instance's CI variables so it's a PITA if you need a CI token which you probably do if you actually make decent use of gitlab's features.

    In most cases I just end up committing my changes to avoid the headache. :!git commit --amend --no-edit && git push -f goes pretty dang fast and 60 % of the time third time's the charm.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 10 months ago* (2 children)

    Why avoid the shell executor on docker? I did 4years of gitlab back a bit ago. It was super simple. But I haven't kept up since work maintains actions and Travis. And there's a way nowadays to inject the env or pull from a secret server-ish.

    All ci is basically the same. Or at least for a while.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 10 months ago (1 child)

    Ideally you'd use the docker executor with a dind service instead of docker commands in the shell. You'll have better isolation (e.g. no conflicts from open port forwards) and better forward-compatibility (the pipeline won't break every time a major upgrade is applied to the runner because the docker - especially compose - CLI is unstable).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 10 months ago

    lots of people already pointed out tools to (kind of) dry run locally. they are great to figure out cryptic error messages.

    however, if you have issues with the complexity of the whole pipeline, it is usually easier to just execute the whole pipeline. for that we have the branch prefix cicd/ and treat these exactly as main/master and develop (except the very last deployment step). that way we can see where a whole pipeline will go. and when it is finally doing what it should, we can squash it before merge -> have a nice history.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 10 months ago

    Yeah, we always try to automate as much as possible with generic language build tooling and scripts, so that ideally the call in the runner is just a single command, which can also be triggered locally.

    Unfortunately, if you want to be able to re-run intermediate steps, then you do need to inform the runner of what you're doing and deal with the whole complexity of up-/downloading intermediate results.

  • permalink
  • fedilink
  • source
  • parent