Split repo trusted setting #4025
Conversation
|
Deployment of preview was successful: https://woodpecker-ci-woodpecker-pr-4025.surge.sh |
|
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? |
|
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. |
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.
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 |
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. |
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. |
I was asking. @anbraten, what did you mean by Agent's feature gates != settings per a repo.
The same way as
Could you elaborate?
To the server/instance admin, if I understand correctly. The same as |
|
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. |
|
@anbraten maybe we can just merge this now as it's ready and discuss the general approach again? |
Still not really convinced how this would really help users and think it mainly ignores UX while complicating existing options. Especially as it doesn't consider org level agents. Anyways will trust you making this helpful at some point. |
|
@qwerty287 lint err |
related to #3758