Refactor GroupDeployKeys model and Introduce FF
Context
In order to start/continue work on GroupDeployKeys UI and API (#232835 & #232837), we need to ensure that the GroupDeployKey
model is treated similarly to the DeployKey
.
Among other things, the GroupDeployKey
should have the same validation checks as the DeployKey
, as well as audit events and expiration notification.
In a previous issue, GroupDeployKeys were introduced with a model that is separate from DeployKeys. (See #14729 (closed) and related MRs). This makes aligning the GroupDeployKey with the DeployKey difficult (see problems mentioned in #330323 and !60809 (closed)).
We want to merge the model of the GroupDeployKey to the DeployKey so that their functionalities/capabilities are better aligned without needing to do a lot of additional work.
Proposal
1. Re-structure the model of GroupDeployKeys
The DeployKey
is just a type
of Key
, and persisted in the keys
table. The DeployKey
is then associated to a project through the deploy_keys_projects
association table. Group-level deploy key should follow the same pattern that DeployKey
is associated to a group through a deploy_keys_groups
(DeployKeysGroup
) association table.
Essentially, the work done in #14729 (closed) will be refactored to follow the above model.
This means we will drop the group_deploy_keys
, group_deploy_keys_groups
tables (and corresponding models) effectively. The GroupDeployKey feature is unfinished, and it is not exposed to any end user, so dropping the tables and classes should be safe to do so.
See discussion: #330323 (comment 1369676048)
2. Introduce a Feature Flag
A Feature Flag should be introduced for the GroupDeployKey so we can hide any incomplete functionalities from the user before the access checks, UI, and API are implemented.
Some changes already introduced in #14729 (closed) may need to be put behind the Feature Flag.
See discussion: &10409 (comment 1369886056)