Add environment_scope column to ci_variables table
Updated: MySQL tests: https://gitlab.com/gitlab-org/gitlab-ce/commits/add-ci_variables-environment_scope-mysql
What does this MR do?
Add environment_scope column to ci_variables table, and update the key unique validation to reflect what we would do in EE.
Why was this MR needed?
We're implementing the feature for EEP at https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112 However it's very tricky to put everything only in EE, while achieve that:
- The least conflicts for each CE to EE merge
- Users could freely upgrade and downgrade between CE and EE
@ayufan has a great idea that we just put the column in CE and update the validation. This would have no impact on CE, because all the rows would just have '*' for this column, and there's no way users could be updating that value, nor use that value, effectively making key unique to [:project_id, :environment_scope] the same as just :project_id.
Users downgrading from EEP to CE could end up with variables with the same key, having different scopes, causing undesired behaviour because they would only get one over the other. However this is on their own because the application certainly won't know which is the desired variable.
They would need to go over their setting page and delete undesired variables, or, just leave them and upgrade back to EEP at some point, if they don't care which variable would be picked over the other. Who knows, they might have the same value and they don't care? We certainly shouldn't pick for them, nor remove the data for them.
We're adding overhead to people purely using CE, but this should have least impact and make everyone else's lives much easier.
See the discussion over https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112#note_33086788
What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112#note_33086788