Dynamic CI secret variables
What does this MR do?
CE backport: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16842
- Update group/project CI/CD secret variables list to use dynamic CI secret variables list just like scheduled pipelines already had.
Projects | Groups |
---|---|
Mobile
Environment scope dropdown
Are there points in the code the reviewer needs to double check?
- BE: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4070
- CE BE: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16439
How to run the QA tests
Replace http://192.168.1.135:3010
with your own GDK IP/port
bin/qa Test::Instance http://192.168.1.135:3010 qa/specs/features/project/add_secret_variable_spec.rb
You can see what is going on with the CHROME_HEADLESS
env option, see https://gitlab.com/gitlab-org/gitlab-qa
CHROME_HEADLESS=false bin/qa Test::Instance http://192.168.1.135:3010 qa/specs/features/project/add_secret_variable_spec.rb
Sub-MRs
- Fix duplicate item in protected branch/tag dropdowns, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16540
- Update secret_values to support dynamic elements within parent, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16665
- Generalize toggle_buttons for JavaScript usage, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16689
- Add
createNewItemFromValue
option andclearDropdown
method tocreate_item_dropdown
, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16699 - Refactor CI variable list code for usage with CI/CD settings page secret variables, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16729
Why was this MR needed?
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
Tests added for this feature/bug - Review
-
Has been reviewed by UX -
Has been reviewed by Frontend -
Has been reviewed by Backend
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Squashed related commits together -
Internationalization required/considered -
If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
Todo
-
Detect change
event on environments dropdown to create new row -
Add in secret_values
and reveal button -
Wait for BE for dynamic group variables -
Hook up ajax call data -
Wait for BE validation messages and print in flash message -
Double check potential e2e tests leftover from removed group/projects /variables
endpoints -
Double check potential links(path helpers _path
) leftover from removed group/projects/variables
endpoints -
Add Karma tests -
Add rspec tests -
Update QA specs, qa/qa/factory/resource/secret_variable.rb
,qa/qa/page/project/settings/secret_variables.rb
,qa/qa/specs/features/project/add_secret_variable_spec.rb
What are the relevant issue numbers?
Edited by Kamil Trzciński (Back 2025-01-01)