Skip to content

Revert "Enable assets caching on security stable branches"

What does this MR do and why?

Revert "Merge branch 'cherry-pick- 7b542758' into '18-1-stable-ee'"

This reverts merge request !196613 (merged)

From !197816 (comment 2628927206):

Recapping our investigation journey, we thought the original MR wasn't working, since it didn't create a cache job on the security mirror (thus this MR). Since then, we learned that it was actually due to the if-not-dot-com-gitlab-org-and-not-jihulab rule, restricting the job from ever being created in the security mirror. (Then actually making it work failed the pipeline, due to the restriction of not having a security package registry).

After we have implemented a security package registry, we can revisit the rules for making the cache job in the security mirror.

The problem with this MR is that we'd be pushing an assets cache every time there's a new commit on the stable branches. In terms of the pipeline efficiency, it doesn't actually affect the overall duration of the pipeline (since the rspec jobs take longer), but the cached assets would still take up a lot of unnecessary storage space in the package registry. So, let's actually revert these changes.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
  • The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
  • The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
  • This MR has a severity label assigned (if applicable).
  • Set the milestone of the merge request to match the target backport branch version.
  • This MR has been approved by a maintainer (only one approval is required).
  • Ensure the e2e:test-on-omnibus-ee job has either succeeded or been approved by a Software Engineer in Test.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

Merge request reports

Loading