How do I realise my weird wish-setup

[mpldr]

Hey, I want to use woodpecker for automating a few tedious tasks I have and for that I have to do some things that are probably considered weird:

• I want to use it "without a forge"
  • clone from ssh://git@git.… which is not a code forge, but rather a server with repos
    • this requires either polling or something like a webhook endpoint
  • authenticate using my own SSO (OAuth2 compatible)
• I would prefer not to have configurations inside the repos themselves
  • now this is the weirdest one, I believe
  • I can easily bypass that by using git-subtree, so optional

What is the final goal? A single source of truth for my repos that is then "published" to code forges if I want it to (for example, don't push commits with a tmp prefix in the message). And more important: do some stuff with sensitive data, I would prefer not to host on a third-party system.

After taking a look at the docs, I am already stumped on how to do the first two points. If development effort is needed, I'll be happy to do the work it takes to make this setup possible.

[qwerty287]

I would prefer not to have configurations inside the repos themselves

This is easy. There's a config service system, see docs: https://woodpecker-ci.org/docs/next/administration/external-configuration-api

I want to use it "without a forge"

This is not really doable without changing code.
Adding a custom forge which actually isn't one is possible by implementing the Forge interface (https://github.com/woodpecker-ci/woodpecker/blob/main/server/forge/forge.go). There, you can easily write funcs that use e.g. an external oauth2 server.

You can even skip webhooks functionality and complete use crons.

However, please note that we will not accept a PR adding something like this. You would have to manage your own fork of woodpecker adding this. If you're fine with this, this should stop you :)

[mpldr]

On Thu Oct 26, 2023 at 8:02 AM CEST, qwerty287 wrote: > I would prefer not to have configurations inside the repos themselves This is easy. There's a config service system, see docs: https://woodpecker-ci.org/docs/next/administration/external-configuration-api

Thanks! I didn't associate that page with that.

> I want to use it "without a forge" This is not really doable without changing code.

To be honest, this isn't unexpected, hence the offer to do the work

Adding a custom forge which actually isn't one is possible by implementing the `Forge` interface (https://github.com/woodpecker-ci/woodpecker/blob/main/server/forge/forge.go). There, you can easily write funcs that use e.g. an external oauth2 server.

Thank you, that is incredibly helpful!

However, please note that we will not accept a PR adding something like this. You would have to manage your own fork of woodpecker adding this. If you're fine with this, this should stop you :)

This however, is somewhat unexpected. May I ask for the reasoning behind that? Without having taken a closer look at the code, I recon this should be possible without introducing too many LoC and I think this may also be useful for developers while debugging.

…

-- Moritz Poldrack https://moritz.sh

See label for sequence.

[qwerty287]

This however, is somewhat unexpected. May I ask for the reasoning behind that?

1. Even if it does not add a lot of code, it will increase complexity and we should try to keep the codebase small.
2. It does not add much use for most people. I don't think many would like to use a setup like this.
3. The maintainers probably won't take care of maintaining and supporting this forge. We had that issue with Gogs, coding and bitbucket before.
4. There is no defined combination of git/oauth server and if there are different combinations with e.g. different api, you'd either need a complex config option or multiple forges which would add a log of code.

We have requests for other forges that were somewhat rejected for similar reasons (especially missing oauth2 which wouldn't apply here of course), see #2355 and #2161.

To fix these issues, I suggested a somewhat different method, the support of go plugins (#2520). That would mean you can develop plugins that are then imported into woodpecker and used as forge or something else. You can then easily add new forges without the need to have it in woodpecker's codebase, they're loaded at runtime. You can then also include forges that were rejected by us for whatever reason.

I recon this should be possible without introducing too many LoC

This depends. If you ignore a lot of features (like hooks), this will of course don't add much code, but otherwise, you can take a look at the other forges, they have about 700 lines or something around this.

I think this may also be useful for developers while debugging.

I'm not that sure, you'll need to set up an oauth service and a git server, you can easily install a gitea instance as dev environment that includes both.

[qwerty287]

I'm going to close this for now as a wontfix for woodpecker's core. The plugin system I mentioned is WIP in #2751 and once it's done you can implement anything as forge whatever you want.

[mpldr]

Yes, that's fine. Additional research has lead me to the conclusion that a simple git-hook does the job as well.

[qwerty287]

@mpldr Starting from 2.1.0, Woodpecker has full support for addons. If you want to, you can realize your setup now by writing a custom addon. See https://woodpecker-ci.org/docs/next/administration/addons/overview