Allow max includes to be changed in application settings
What does this MR do and why?
This MR converts the hardcoded limit of MAX_INCLUDES
into an application setting ci_max_includes
. The application setting can be changed via the UI in Admin Settings or updated via the API.
This setting affects how many include files are allowed in the CI pipeline config. The default value is 150
.
Resolves #207270 (closed)
Screenshots
New Maximum includes
setting in Admin > Settings > CI/CD > Expand "Continuous Integration and Deployment"
How to set up and validate locally
- Run the migration:
bundle exec rails db:migrate
- Set up a circular includes situation so that we can easily see the current maximum includes value being used. You can do this by updating your project's
.gitlab-ci.yml
with the following:
include: .gitlab-ci.yml
When you attempt to run the pipeline you should see the following error. Notice that the default value is 150
.
- Change the application setting via the UI. Go to Admin > Settings > CI/CD > Expand "Continuous Integration and Deployment" and change the value of
Maximum includes
to123
. Click "Save changes".
Attempt to run the pipeline again and observe that the error now shows 123
.
- Change the application setting via the api by running the following command in the terminal. (Adjust the host and token as needed).
curl --request PUT --header "PRIVATE-TOKEN: <your-access-token>" "http://gdk.test:3000/api/v4/application/settings?ci_max_includes=95"
Observe that the response shows the updated value:
You can also attempt to run the pipeline again and observe that the error now shows 95
.
- Just for extra measure, and to ensure we haven't just been updating the error message (
😆 ), we can update the setting to2
.
Create a child.yml
file with the following content:
job:
script: echo
Then update your .gitlab-ci.yml
with 3 include files like so:
include:
- local: child.yml
- local: child.yml
- local: child.yml
Run the pipeline and observe that there is a validation error.
And if you then update your .gitlab-ci.yml
with just 2 include files, there is no validation error and the pipeline runs successfully.
Migration
bundle exec rails db:migrate
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrating ============
main: -- add_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
main: -> 0.0048s
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrated (0.0142s) ===
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrating ============
ci: -- add_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
ci: -> 0.0047s
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrated (0.0110s) ===
VERSION=20230421165020 bundle exec rails db:migrate:down:main
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverting ============
main: -- remove_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
main: -> 0.0024s
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverted (0.0080s) ===
VERSION=20230421165020 bundle exec rails db:migrate:down:ci
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverting ============
ci: -- remove_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
ci: -> 0.0024s
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverted (0.0113s) ===
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #207270 (closed)