I'm trying to wrap my head around how to get my #docker #DroneCI (docker) pipeline to publish my final builds to the machine it's on.

Ideally I'd like it to do a direct transfer (scp or rsync) without having to hit the LAN.

Idk if the pipeline builds exist on the same docker network as the host image; are they allowed to communicate directly? If so then does that mean the network that Drone is in, that the pipeline image can communicate with another hosted service?

A bit over a year ago, I set out to replace my CI. As of a few days ago, the adventure concluded, I fully migrated every project I care about off of #DroneCI to #Forgejo Actions.

It's not perfect, not by far. But it's a better fit for me than any other alternative I considered then, and since. It's Good Enough that I no longer feel the need to write my own (at least, not anytime soon). I'll take that win.

So I took a quick look at this new #Gitness thing by #Harness (who also bought #DroneCI in 2020), and... wow. It's just #DroneCI with a very barebones "Forge" support slapped on top. You can navigate the repo, there's support for pull requests and CI pipelines.

No issues, however. No projects. No package registries.

And on top of that, an UI that's slow. I go to the repositories list, and the single repo I imported (with a whole 3 commits to a single README) appears 2(!) seconds after the rest of the page loads.

How can you even consider announcing a forge without support for issues? With an UI that's closer to Jira than to anything remotely usable?

This is gonna be a hard pass. Mind you, I would've dismissed it even if it was a viable alternative, because I don't trust Harness to keep it open source. They didn't do that with Drone, why would they do it with Gitness? Feels better to dismiss it because it's not a viable alternative, though.

The announcement is surprising, however. This isn't even MVP, let alone something worth to announce.

I've been poking at my #Forgejo Actions setup these past few days, and I got to a point where I think I know what I'm doing. At least some of the time.

Figured this would be a good point to try and translate the #DroneCI workflow I have for riemann-c-client (screenshot of the workflow's partial dependency graph is attached) to Forgejo.

It... will be difficult. There are a few pain points:

• The current Drone workflow starts by building a common base image, and reuses that for almost every other job. This is a bit harder to accomplish with Forgejo. Not impossible, but a bit harder. However, it may not be necessary at all.
• The current Drone workflow has a lot of repetition I'd like to get rid of.
• I figured I'll use reusable workflows! Those... work, but the UI part of it is horrible. All output is in the "Set up job" step (see here). That's not gonna work.
• I can get rid of most of the duplication by using custom actions from within the same repo, but then I lose a bit of granularity. The current Drone workflow has the configure/build/test steps separated, and while I can do that with actions, I'd have to repeat the parameters for all three steps.
• GitHub actions has a way of grouping output, but Forgejo's UI (or Act, or whichever part is responsible for that) doesn't support that yet, so I can't make use of that, either.
• Part of the test suite involves running Riemann as a service. I can do that with Forgejo actions fine. But I also need TLS certs for it, which I do not ship, and have to generate. Services can't have dependencies with Forgejo Actions, so I'll have to figure something out about that.