Why is this team sticking multiple directories that are “independent of each other” into a single repository? This sounds like a clear case of doing version control wrong. Monorepos come with their own set of challenges, and I don’t think there are many situations where they’re actually warranted. They certainly don’t help for completely independent projects.
I'll think twice before using GitHub Actions again
81–90 of 284 posts
Re: I'll think twice before using GitHub Actions again
#82I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline. With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.
What does this even mean? Are you talking about Forgejo Actions, or are you somehow hosting your code on a Forgejo instance but running CI through GitHub?
> With Woodpecker/Jenkins you know exactly what your pipeline is doing.
If you wrote it from the ground up, sure. On the other hand, I've inherited Jenkins pipelines that were written years before I got there and involved three to four different plugins, and they're way worse to work with than the GitHub Actions that I inherited.
Re: I'll think twice before using GitHub Actions again
#83If this is true, and you still have problems running specific Actions, why not break this into separate repositories?
Re: I'll think twice before using GitHub Actions again
#84Earlier quoted context omitted.
At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.
But you can do the same with GitHub, right? Although most docs and articles focus on 3rd party actions, nothing stops you to just run everything in your own shell script.
Re: I'll think twice before using GitHub Actions again
#85Earlier quoted context omitted.
I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…
My "favorite" is when I see people go all in, writing thousands of lines of Jenkins-flavor Groovy that parses JSON build specifications of arbitrary complexity to sort out how to build that particular project. "But then we can reuse the same pipeline for all our projects!"
The few bits that end up getting reused are the externalized bash scripts.
Re: I'll think twice before using GitHub Actions again
#86Earlier quoted context omitted.
I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…
it can be quite hard to write proper scripts that work consistently... different shells have different behaviours, availability of local tools, paths, etc and it feels like fighting against the flow when you're trying to make it reusable across many repos
Re: I'll think twice before using GitHub Actions again
#87I wrote about it in detail https://ashishb.net/tech/common-pitfalls-of-github-actions/ And even created a tool to generate good configs http://github.com/ashishb/gabo
Re: I'll think twice before using GitHub Actions again
#88I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline. With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.
Re: I'll think twice before using GitHub Actions again
#89Oh boy, there's a special kind of hell I enter into everytime I set up new github actions. I wrote a blog post a few months ago about my pain[0] but one of the main things I've found over the years is you can massively reduce how horrible writing github actions is by avoiding prebuilt actions, and just using it as a handy shell runner. If you write behaviour in python/ruby/bash/hell-rust-if-you-really-want and leave…
At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.
I’m not even sure when I started feeling like that was a bad thing. Probably when they started glueing a bunch of badly executed security crud onto the main product.
Re: I'll think twice before using GitHub Actions again
#90Earlier quoted context omitted.
it can be quite hard to write proper scripts that work consistently... different shells have different behaviours, availability of local tools, paths, etc and it feels like fighting against the flow when you're trying to make it reusable across many repos
Containerize the build environment so everything is captured (dependencies, build tools, etc)