841–850 of 853 posts
Earlier quoted context omitted.
I initially felt a bit offended when I saw this. Then I thought about it and at the end of the day there's a decent amount of infrastructure that goes into displaying the build information, updating it, scanning for secrets and redacting, etc. I don't know if it's worth the amount they are targeting, but it's definitely not zero either.
Does it make sense to accept charge per minute when you are hosting yourself? When GHA is not very good?
Earlier quoted context omitted.
top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'
We call ours "bombing-range" We maintain an internal service that hosts two endpoints; /random-cat-picture (random >512KB image + UUID + text timestamp to evade caching) and /api/v1/generic.json which allows developers and platform folks to test out new ideas from commit to deploy behind a load balancer in an end-to-end fashion, it has saved countless headaches over the years.
Earlier quoted context omitted.
> You can run all your CI locally if you can, you don't need CI. we can't (too slow, needs an audit trail)
I think the idea is GitHub actions calls "build.sh", or "deploy.sh" etc. Those scripts contain all of the logic necessary to build or deploy or whatever. You can run those scripts locally for testing / development, or from CI for prod / auditing.
Use open source software. Buy your own compute. Make the effort. It's worth it.
I'm kind of ok with renting compute so long as it's running open source software. Basically I'll gladly pay for a service, but I don't like getting locked into that service. If the payed service is using FOSS, I will always have the option to migrate if the provider starts to misbehave
Earlier quoted context omitted.
Jenkins is in every way a “Java” program, and not the good kind. What you can say for it, is that it was free and near infinitely hackable.
I use Jenkins every single day, and have been using it my entire career through three different companies self hosting it. Please tell me how we somehow have been hobbled despite having simple and clear pipelines setup that autobuild any branch we want and allow one click deploys to our preprod environment and automatically manage versioning and scalably handle load from "Literally zero" to "Everyone in the company w…
Multibranch is still weird and obviously added-on.
Writing plugins is ugly.
Earlier quoted context omitted.
Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed. As a really big bonus, that also makes your CI testable. In the previous job, we built such a thing: https://smarketshq.com/building-a-repr…
Yes, totally agreed in theory, and it sounds like y'all built a great solution for your use case. But it takes substantial effort and discipline to do something like that at scale. At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.
More than 6 years users of OneDev (onedev.io). - Git repo - Ticketing, Kaban - Full helpdesk - Complete and full CI/CD - everything links via custom workflow - self hosted I still dont know why everyone hasn't switch yet to that banger.
I really wanted to like it but the UI always put me off. Also tending to prefer a more open development model these days. Thankfully at least for dev gitea and forgejo have both come a long way and the CI is pretty decent now (though they still dont have a gui workflow builder!).
OneDev is not fully open (there are some module for paid user), but Robin is truly available, even if the only and main developer, on every ticket you open or feature you request.
I really appreciate its awesome work
Earlier quoted context omitted.
You don't need your own user. The rest is correct. (Though you can hardlink the installation.) And you can disable self-update, though it does it by default.
Ah right, I've forgotten because I'm using a multi-user strategy and a patched version of the runner at this point anyway. The config directory for each runner is normally based on its install path (insane), something like that?
To be fair, running multiple copies of a service isn't that common.
E.g. if you wanted to run multiple copies of PostgreSQL you can't just do a vanilla install.
Earlier quoted context omitted.
How do they abuse self hosted runners?
Malware in build scripts/dependencies. That's not exclusively credential/crypto-stealers, there's apparently also a healthy demand for various types of spam straight from corpo gateways...