145
"GitHub CI is easy", he said. "It's just bash ", he said. (programming.dev)
submitted 6 days ago* (last edited 6 days ago) by ulterno@programming.dev to c/programmer_humor@programming.dev
36 comments fedilink hide all child comments

Until he actually had to use it.

Took 2 hours of reading through examples just to deploy the site.
Turns out, it is hard to do even just the bash stuff when you can't see the container.

you are viewing a single comment's thread
view the rest of the comments
[-] akash_rawal@lemmy.world 34 points 6 days ago* (last edited 6 days ago)

Time for the yearly barrage of "Setup CI"..."Fix CI" commits.

That is my experience with basically every CI service out there.

[-] frezik@midwest.social 21 points 6 days ago

Normally, you don't want to commit code unless it's been at least minimally tested, and preferably more than that.

All the CI's, however, force a workflow where you can only test it by committing the code and seeing if it works. I'm not sure how to fix that, but I see the problem.

[-] smeg@feddit.uk 16 points 6 days ago

If you can test it on a feature branch then at least you can squash or tidy the commits after you've got them working. If you can only test by committing to main though, curse whoever designed that.

[-] ulterno@programming.dev 2 points 6 days ago

Well, it does have triggers for other branches:

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

So, most probably would have a way to run it on other branches.

[-] odelik@lemmy.today 6 points 6 days ago

You can also use the workflow_dispatch execution pattern and use some data input params and execute through the portal interface.

However, do be careful about trusting input params without sanitizing them (GH has docs around this).

[-] ulterno@programming.dev 0 points 5 days ago

Thanks, I'll look into that.
While trying this time (as you can see in one of the commits), I added workflow_dispatch at the wrong place, causing a problem. Later realised that it is part of the on

[-] houseofleft@slrpnk.net 10 points 6 days ago

Here's my hot tip! (ok maybe luke warm)

Write as much of your CICD in a scripting language like bash/python/whatever. You'll be able to test it locally and then the testing phase of your CICD will just be setting up the environment so it has the right git branches coined, permissions, etc.

You won't need to do 30 commits now, only like 7! And you'll cry for only like 20 minutes instead of a whole afternoon!

[-] marzhall@lemmy.world 3 points 5 days ago

Aggressively seconding this. If you can just do a step in a bash command, do that, don't use the stupid yaml wrapper they provide that actually just turns around and runs the same bash command but with extra abstraction to learn, break, fix, and maintain for stupid, meaningless upgrades. It will save you time because you'll be using better-tested, more widely-used tools and approaches.

[-] frezik@midwest.social 2 points 6 days ago

Yeah, I think that's the best that can be done right now.

It also leads to a different question: do we really need these fancy systems, or do we need a bunch of bash scripts with a cronjob or monitors to trigger the build?

[-] ulterno@programming.dev 0 points 6 days ago

In my last workplace, I was responsible for making whatever automation I wanted (others just did everything manually) and I just appended a bunch of bash scripts to the Qt Creator Build and Run commands. It easily worked pretty well.
I guess the fancy systems are again, just to add another layer of abstraction, when everything is running on their containers instead of ours.

[-] Ajen@sh.itjust.works 2 points 5 days ago

Line the other commenter said, there's nothing wrong with committing temp/untested code to a feature branch as long as you clean it up before the PR.

[-] frezik@midwest.social 1 points 5 days ago

There are issues that come up in niche cases. If you're using git bisect to track down a bug, a non-working commit can throw that off.

[-] Ajen@sh.itjust.works 4 points 5 days ago* (last edited 5 days ago)

You might have misunderstood what I meant by "clean up before the PR." None of the temp commits should end up in the main branch, where people would be bisecting.

[-] akash_rawal@lemmy.world 1 points 6 days ago

We test our code locally, but we cannot test the workflow. By definition, testing the workflow has to be done on a CI-like system.

There is nektos/act for running github actions locally, it works for simple cases. There still are many differences between act and github actions.

It might be possible for a CI to define workflow steps using Containerfile/Dockerfile. Such workflows would be reproducible locally.

this post was submitted on 13 Nov 2024
145 points (98.0% liked)

Programmer Humor

19594 readers
831 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev