Optionally use new dry_run mode on CI Lint page
What does this MR do?
Related to #229794 (closed)
In !37134 (merged) we introduced a new mode in Ci::CreatePipelineService
called dry_run: true
which would skip persisting the pipeline while letting everything else happening. In the end, a non-persisted pipeline is returned including any errors and (recently added) warnings.
In this MR we change the CI Lint web page to use the dry_run
mode and pass in the content to validate.
Feature Flag
These changes are done behind a feature flag disabled by default: ci_lint_creates_pipeline_with_dry_run
. After deployment to production the FF will be enabled and a MR will be created with changing it to default_enabled: true
.
Limitations
This feature currently uses some static parameters like ref
, :push
source but we could add a form in the UI to allow users insert custom parameters to simulate different contexts (various sources like schedule, merge requests, etc. - ref - variables - commit message - etc). Because of that only maintainers
(with permissions to run pipelines on master) can see and use this feature, until other parameters will be supported.
Performance
- Given that we will be using the full pipeline creation process rather than just
YamlProcessor
we expect that response times to CI lint controller and API will increase.
Screenshots
Using dry run mode
- check the checkbox - the (?) icon should bring the user to the documentation page
- click
Validate
button
Before (checkbox disabled)
Certain validations that occurred at an advanced stage of pipeline creation are not caught by the current CI Lint (default mode).
After (checkbox enabled)
With dry run enabled we are able to provide the actual errors.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team