Subnostr

Jenkins' specialty is the job scheduling and parallelization and dispersal.

Well guess I haven't used it enough then. I had a really hard time getting it configured last I set it up, I had run a few jobs on it but was running into agent issues and switched to oneDev in my search and here we are. OneDev doesn't have any systems to manage hardware queuing. I can get very good with paralellization and caching, but just wasn't made for scheduling and queuing. This might be solvable with scripts but we just shouldn't need it. No team really should.

I also remember Jenkins also being built for teams, not SaaS use so we'd need an abstraction layer, assuming it has a decen't api.

Reply to this note

Please Login to reply.

Discussion

Laeserin 9mo ago

Couldn't you just assign people agents, or something, and track that way? Have a limit, per agent, and then throttle after that? Just make it part of a premium offering.

ChipTuner 9mo ago

I just don't think onedev is good for the job in that case. Jenkins can at least be run outside of the repository as an extension service.

Kind of I suppose. It would be over my head at the moment. You can assign executors to a job, and agents to an executor, but throttling doesn't really solve a schedueling issue.

It's a backward stop-gap imo not worth using if starting from scratch. Real hardware scheduling would be better imo. So user Y's job gets queued after user X's and make more efficient use of the agent service.

Stacking multiple agents on the same machine just consumes more resources that are already expensive. The goal would be to use the same resources and just better schedule use of them.

Silberengel 9mo ago

I meant, with Jenkins.

ChipTuner 9mo ago

roger

Silberengel 9mo ago

I'm thinking that we should just try to launch fast and extremely minimal, with the Nostr login/messaging feature implemented on an HTTP git server and coordinated with the relay, and then create something more fancy and feature-rich later, and offer that for a premium rate.

It could even be two distinct git servers on two different machines, as the repos will be identifiable by their ability to write to the wss://thecitadel.nostr1.com relay, and the repo events the subscribers upload would all appear together on the GitWorkshop page, regardless of which services they rent from us. We could add a little 🛡️ emblem to premium subscribers, or something, to make them stand out from the crowd a bit.

But that all seems like something we could do, later.

ChipTuner 9mo ago

Oh yeah I'm actually hoping it's completely separate, and I have no inetentions of implementing CI soon. No feature creep. Hoping for a very basic git remote compatible with git and ngit.