We should have the ability to add a \<thing> to a denylist, that used in conjunction with a corresponding allowlist, helps fine-tune access.
We currently have a Repo Allowlist and Schedule Allowlist. The addition of User Allowlist, Repo Denylist, Schedule Denylist, and User Denylist, greatly enhances the ability to quickly control access.
For example, if Repo Allowlist is set to the default * (all repos), but just a subset of org/repos should be blocked, we would have to individually add all org/* and/or org/repos to the list, except those to be blocked.
With both lists, we can still keep the allowlist to be * (all repos), but also have org/repo's in the denylist. Much easier to maintain.
Error messages should include appropriate amount of detail, tbd, perhaps clarifying blocked by admin, contact admin for access or similar.
One benefit is if an admin determines a repo needs to be blocked on the fly due to behavior affecting the platform, it can quickly be blocked so the admin can focus on troubleshooting.
Missed opportunity with Repo Allowlist: enabled repos that are no longer in the repo allow list should be blocked from running new builds.
If a repo is enabled, and then a platform admin removes it from the repo allow list (or the repo allow list is updated from all repos to only allow certain repos), current behavior is the repo is still able to run builds (restarts and new commits).
Ideal behavior is updating the repo allow list should prevent these builds.
Value
Platform admins can have confidence in which repos/users are allowed or prevented from running builds.
Description
We should have the ability to add a \<thing> to a denylist, that used in conjunction with a corresponding allowlist, helps fine-tune access.
We currently have a Repo Allowlist and Schedule Allowlist. The addition of User Allowlist, Repo Denylist, Schedule Denylist, and User Denylist, greatly enhances the ability to quickly control access.
For example, if Repo Allowlist is set to the default
* (all repos), but just a subset of org/repos should be blocked, we would have to individually add all org/* and/or org/repos to the list, except those to be blocked.With both lists, we can still keep the allowlist to be
* (all repos), but also have org/repo's in the denylist. Much easier to maintain.Error messages should include appropriate amount of detail, tbd, perhaps clarifying
blocked by admin,contact admin for accessor similar.One benefit is if an admin determines a repo needs to be blocked on the fly due to behavior affecting the platform, it can quickly be blocked so the admin can focus on troubleshooting.
Missed opportunity with Repo Allowlist: enabled repos that are no longer in the repo allow list should be blocked from running new builds.
If a repo is enabled, and then a platform admin removes it from the repo allow list (or the repo allow list is updated from
allrepos to only allow certain repos), current behavior is the repo is still able to run builds (restarts and new commits).Ideal behavior is updating the repo allow list should prevent these builds.
Value
Platform admins can have confidence in which repos/users are allowed or prevented from running builds.
Useful Information
vela --version?v0.24.0