Specify SAST_REPORT_URL or DS_REPORT_URL for downstream project
What does this MR do?
Migrates the downstream QA expectations to the analyzer project, born out of gitlab-org/gitlab#33724 (comment 316429535), this will be our attempt at reducing circular dependencies and having a more stable versioning for our analyzer/test projects
-
ci-templatesupdates to pull in passed expectation gitlab-org/security-products/ci-templates!84 (merged) -
apex-salesforcetest branch to use CI template (NOTE: expectation has been removed): https://gitlab.com/gitlab-org/security-products/tests/apex-salesforce/-/blob/allow-expectation-to-be-specified-for-downstream-qa-jobs/.gitlab-ci.yml
What are the relevant issue numbers?
gitlab-org/gitlab#224541 (closed)
Also relates to gitlab-org/gitlab#33724 (closed)
Does this MR meet the acceptance criteria?
- [-] Changelog entry added
-
Documentation created/updated for GitLab EE, if necessary -
Documentation created/updated for this project, if necessary -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Job definition updated, if necessary -
Conforms to the code review guidelines -
Conforms to the Go guidelines -
Security reports checked/validated by reviewer
Merge request reports
Activity
mentioned in merge request bundler-audit!35 (closed)
mentioned in merge request gitlab-org/security-products/ci-templates!84 (merged)
added 1 commit
- 71130552 - Specify SAST_REPORT_URL for downstream project
@dsearles @fcatteau would each of you mind reviewing this? This pairs with gitlab-org/security-products/ci-templates!84 (merged) to demonstrate the new template and once this one looks good, I can update this secondary MR to remove the necessary pointing at the template branch
changed milestone to %13.2
added backstage [DEPRECATED] devopssecure groupstatic analysis test labels
unassigned @dsearles
Resolved by Fabien Catteau@theoretick Great! It works, and it's clean. So I'd like to approve...
That said, I don't have the big picture in mind. I guess I should reread everything starting from this comment where I discuss "A" versus "B".
To recap, I see two ways we can ease the pain:
-
A. change the CI configuration shared by the analyzer projects so that a MR isn't blocked when the generated report doesn't match the expected one, while still making sure the change is properly reviewed
-
B. move the expected reports to the analyzer projects, so that they are updated and reviewed in the MR where the behavior of the analyzer project is changed
So that would be B, right? We would move the expected reports back to the analyzer projects, right? That seems pretty expensive, and I'd say we need to discuss this in an issue, and come up with a migration path. WDYT? In that issue, I'd like to discuss the scheduled pipelines we currently have in our test projects, among other things.
Or are there other scenarios where being able to set the URL of the report helps? If so, I'd be happy to approve right away!
-
- Last reply by Fabien Catteau
mentioned in issue gitlab-org/gitlab#224541 (closed)
assigned to @theoretick and unassigned @fcatteau
assigned to @dsearles and unassigned @theoretick
mentioned in commit 865d977a
