Split repo trusted setting

[qwerty287]

related to #3758

[woodpecker-bot]

Deploying preview to https://woodpecker-ci-woodpecker-pr-4025.surge.sh

[qwerty287]

Actually you can start taking a look here. There are probably still some issues but for the general concept.

This is currently a breaking change (changes API), we could either get it into 3.0 or make it non-breaking, what do you prefer?

[zc-devs]

get it into 3.0

[anbraten]

I am not really a fan of this split. Although I kinda see the general idea behind it, it complicates the CI (not really interested to move towards Jenkins and similar tools) and it shifts the security guidelines from the agent admin to the repo admin. Therefore multiple agents aren't able to provide different settings.

[qwerty287]

it shifts the security guidelines from the agent admin to the repo admin.

Repo admins can't change this setting if they're not a server admin and usually the server admin is also the agent admin I think.

Therefore multiple agents aren't able to provide different settings.

That's a general issue, but it's impossible to deal differently with our current structure. You would need to change the whole system and give the agents more capabilities (for example, the server must not parse the YAML anymore. This must be done by agents as well).

Also, this issue is not different from how it works now. Enabling trusted is currently also on repo-level and this PR does not give any way to get more privileges than before.

[6543]

migration fail related !!!

https://ci.woodpecker-ci.org/repos/3780/pipeline/20192/36

[anbraten]

Not confined by the benefit of splitting the setting.

[anbraten]

Repo admins can't change this setting if they're not a server admin and usually the server admin is also the agent admin I think.

Isn't that the reason why this is currently an agent config (at least for the kubernetes options). It would only make sense for smaller deployments where server admins are agent admins as well I guess. For larger teams / orgs with or when supporting #267 those options would be quite unimportant.

[zc-devs]

this is currently an agent config (at least for the kubernetes options)

Where?

this issue is not different from how it works now. Enabling trusted is currently also on repo-level and this PR does not give any way to get more privileges than before

[qwerty287]

Where?

You mean the "feature gates"?

Tbh I think this somehow would be a mess. Or we refactor our whole structure, e.g. the agent would have to parse the YAML and not the server. Also, having it on a repo level additionally can still be helpful as you might have repos that shouldn't be able to use some features.

[zc-devs]

You mean the "feature gates"?

I was asking. @anbraten, what did you mean by agent config? Could you provide an example?

Agent's feature gates != settings per a repo.

having it on a repo level additionally can still be helpful as you might have repos that shouldn't be able to use some features

---

it complicates the CI

The same way as trusted does.

not really interested to move towards Jenkins and similar tools

Could you elaborate?

it shifts the security guidelines from the agent admin to the repo admin

To the server/instance admin, if I understand correctly. The same as trusted. And doesn't shift, but adds per repo settings.

[6543]

Maybe using ALTER TABLE DROP COLUMN will help. server/store/datastore/migration/common.go:dropTableColumns(...)

Offtop: I thought, ORM/migration tool should do this magic. Seems, I was wrong :)

ORM dont just drop data ... you have to specify that

[6543]

As for the current structure I'm quite happy as it works (some strings atached...) but to cover the concerns ... an agent admin should be able to optionally overwrite security related things set by the server, if veasable like e.g. deny to mount volumes pointing to non docker volumes e.g. to the host ...

But that has to be a backemd option as each backend has different security considderations

[qwerty287]

Yes, and it is a totally different part than this PR.

[anbraten]

As we moved resource settings #3174 to the agent and as we will have #3539, I still think we should move such settings to the agent. My current idea would be to use filters like allows.volumes=true instead, so only agents supporting volumes would pick up your workflow.

[qwerty287]

I understand your point, but it is not as flexible as it is currently. If you currently have a few repos that are trusted and some not, you was able to do that with one agent. With this new system, this wouldn't be possible anymore.