Excellent read! We were talking about the effects of AI Psychosis on companies. It looks like people have a misconceived notion that now work can be done 90% faster and they are attempting to literally get rid of 90% of the engineers. The end result, no one left with do the work - especially when an edge case/disaster strikes or the customer wants something different.
It's based on act[0] so it's quite like GitHub actions but not completely [1].
I found in the current version of Forgejo the most secure way to set it up was just to put the runner on a different host. There's a Docker in Docker setup [2] that was challenging to get working correctly but still didn't quite feel secure...
After setting it all up, I'm convinced GitHub actions as a concept is flawed. I wish the community would make a simpler git-defined CI/CD that didn't have the crazy surface area that actions does... Named shell scripts that can call out to other stuff in the runner Docker image and report it to the UI would be a nice start.
Agreed. GitHub Actions feels like someone's science project created while on a mushroom trip. Really you just want a thing that executes a shell script in a runner.
You can use any CI/CD you want. The only reason GH is popular is that it's free for public repos.
But Forgejo does have a GH like CI/CD. If you really care about good CI/CD then you should try some of the alternatives out and decide what works best for your needs.
> The only reason GH is popular is that it's free for public repos.
It's also free for private repos, and I have both. Codeberg doesn't like private repos, so unfortunately I cannot just move everything to Codeberg. I'll probably set up a Forgejo VPS somewhere.
For a forgejo host, check codefloe.com if what you need is a place to host personal projects or smaller teams. It’s been rock solid and it is now the default choice for anything outside of work I’ll do.
I don't have any specific recommendations other than do as little in your CI/CD as possible, instead do as much as possible in your build system or scripts that get called by CI/CD. This way you can migrate with less work or run locally when you want.
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop
Just set up a CI pipeline for PHP projects with a forgejo runner last week. Tried many approaches, ended up with a simple debian VM. Runner works well with docker images inside the VM, quite a flexible setup.
Found this easier and better than my last tries a few years ago with gitlab, which always felt quite bloated.
If you know GitHub actions then you’ll immediately understand Forgejo actions. It was designed that way intentionally. There are some differences, but at least for me not enough to warrant any pitchforks.
If you have advanced use cases you might be more frustrated, but I’m not aware of any off the top of my head. I think my biggest complaint is that they haven’t exposed action logs over the API, so I can’t build tooling around them at the CLI level, feed them to an LLM, or more quickly diagnose problems that arise without using the website.
Same experience. It took minutes to find the API key from the console.
Now following up with Google support team without luck to find the logs. Prompts send to the model and the responses including the thinking was available in the ai studio. But it’s unclear where to find the same in console.
To make matters worse there is vertex api and rebranded to Gemini something and making it very confusing.
They have support for long format and the industry is already attempting long shots with Seedance 2.0 which cannot be efficiently done without drift in other leading models like Kling.
Excellent. We already tested at okayish scale of 5 million messages per minute, with each message being less than 1KiB. Do note that NATS can easily handle 100x this scale. It's just what we had tested during initial days.
I have a stupid question - as I understand NATS works very well as a “message” pipe/bus. Anyway to get Redis type cache functionality as well ? Is it something possible ?
Thank you! Jetstream looks useful. For a platform which is production our Redis costs are getting prohibitively high. I was on the look for alternatives and perhaps in the software reliability tool [0] I am buildin try out Jetstream.
Not sure whether this is the right step. Rather steps must be taken to ensure reliability of the software irrespective of whether it’s “written” or “generated”. The code generation based on “rules” is not new after all.
The leader boards based on token usage happened in our org for a month. Then we managed to convince the board that what matters is the reliable software shipped. Now we are back to DORA metrics.
reply