411–420 of 584 posts
Stop rebasing.
This should only happen if absolutely necessary to fix major merge mistakes.
Rebasing changes history and I've seen more problems prevented from removing it as a CI strategy.
Every CI strategy I've seen relying on rebasing had a better alternative in SDLC. You just need to level up your project management, period.
There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…
Earlier quoted context omitted.
> gorilla consulting Probably 'guerilla', but I like your version more.
Haha, I'm gonna admit it, all these years and I thought gorilla/guerilla was one of those American/British spelling things, like cheque/check or gaol/jail. Boy do I feel stupid.
GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted. It's really upsetting how little attention Actions is getting these days ( https://github.com/orgs/community/discussions/categories/act... > tells the story -- the most popular issues have gone completely unanswered). Sad to see Earthly halting dev…
We switched to Depot last week. Our Rust builds went down from 20+ minutes to 4-8 minutes. The easy setup and their docker builds with fast caching are really good.
GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted. It's really upsetting how little attention Actions is getting these days ( https://github.com/orgs/community/discussions/categories/act... > tells the story -- the most popular issues have gone completely unanswered). Sad to see Earthly halting dev…
Example:
https://github.com/actions/runner/pull/2477#issuecomment-244...
Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…
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…
- Everything sandboxed in containers (works the same locally and in CI)
- Integrate your build tools by executing them in containers
- Send traces, metrics and logs for everything at full resolution, in the OTEL format. Visualize in our proprietary web UI, or in your favorite observability tool
But, there are so many red flags in this post. Clearly this corp does not know how to build, test and release professional software.
> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I'm surprised nobody has mentioned dependabot yet. It automates this, keeping action dependencies pinned by hash automatically whilst also bringing in stable upgrades.
Well but that’s the problem. You cannot fully automate this. You have to manually check the diff of each dependency and only accept the dependabot PR if the changes are safe. The only automation that I know of is cargo vet. Although it doesn’t work for GitHub Actions, the idea sounds useful. Basically, vet allows people who trust each other to vet updates. So one person verifies the diff and then approves the changes…
Earlier quoted context omitted.
> I know some people might consider this insanity Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. This is insane. You’re actually introducing much needed sanity into the process by admitting that a real programming language is the tool to use here. I can’t imagine the cognitive dissonance Lisp folks have when dealing with this madness, not be…
> Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. I've been using YAML for ages and I never had any issue with it. What do you think is wrong with YAML?
Some people talk about YAML being a turing complete language, if people try to do that in your CI/CD system just fire them
I'll allow helm style templating but that's about it.
Earlier quoted context omitted.
> Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. I've been using YAML for ages and I never had any issue with it. What do you think is wrong with YAML?
Turing complete YAML ends up being an app specific terrible programming language. Many of us would rather use a less terrible programming language instead.