@narendran-kannan
Ok. I may have a look later, I am focusing on deliverables for the moment.
| Before | After |
|---|---|
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Miguel Rincon (239c1c75) at 17 Mar 15:47
Migrate lodash imports to lodash-es
@xanf, alright, let me take a step back. What I was saying is that our build process has 3 modes, which can be represented by a single variable as they are mutually exclusive. I chose VUE_VERSION because it is already wired in our GDK and pipelines, but suppose it has any name:
VUE_COMPILER_VERSION=2 + VUE_VERSION=2 => CONFIG=A (we could reuse VUE_VERSION=2)VUE_COMPILER_VERSION=3 + VUE_VERSION=3 => CONFIG=B (we could use VUE_VERSION=3)VUE_COMPILER_VERSION=2 + VUE_VERSION=3 => CONFIG=C (we could use VUE_VERSION=hybrid)VUE_COMPILER_VERSION=3 + VUE_VERSION=2 => invalid, like you say :)Leveraging VUE_VERSION in the context of the env vars we already have makes sense to me, and it is not too confusing. Hope this makes more sense.
EDIT: Typos
VUE_VERSION=hybrid would do the same as setting VUE_COMPILER_VERSION=3, and we haven't opted-in yet, as we are testing the infection plugins solution, correct? That's what a single setting can help control.
@markrian @xanf this reminds my of a suggestion I left elsewhere: VUE_VERSION could take one of 3 values: 2, hybrid or 3. gdk.vite.vue_version and gdk.webpack.vue_version already populate it.
This would enable us to drop VUE_COMPILER_VERSION, as VUE_VERSION is all we need to know during our build moving forward, wdyt?
(Apologies for not testing this myself, I've been lurking as I have been focusing on deliverables)
Note: I want to have view_group_ci_cd_analytics as the SSoT for access to this page, as later I'll add more features to the same page, they should all be under the same policy in OR
view_group_ci_cd_analytics is enabled when group_ci_cd_analytics_releases OR group_ci_cd_analytics_pipelines are available.
I removed this line already.
True! In the next MR I plan to have group_ci_cd_analytics_available become true if either group_ci_cd_analytics_releases OR (new) group_ci_cd_analytics_pipelines is true.
This should enable the page I am panning to add at !226873.
Miguel Rincon (013a3ade) at 17 Mar 14:56
Renamed the licensed feature group_ci_cd_analytics_releases
Miguel Rincon (6ee247b4) at 17 Mar 14:54
Renamed the licensed feature group_ci_cd_analytics_releases
Note: This block was duplicated to the one above at :517, must have been a mistake during a merge conflict resolution.
Renamed the licensed feature group_ci_cd_analytics to group_ci_cd_analytics_releases
This change renames the licensed feature group_ci_cd_analytics to group_ci_cd_analytics_releases to make it more specific, and so our team can add another feature under the group_ci_cd_analytics_ prefix in an upcoming release.
Why now: For #591744 we will add a separate group_ci_cd_analytics_pipelines feature in GitLab Premium that is separate from group_ci_cd_analytics. This helps keep the responsibilities separate.
Related URL: https://gdk.test:3000/groups/my-group/-/analytics/ci_cd
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #591744
Miguel Rincon (21d6899d) at 17 Mar 14:48
Renamed the licensed feature group_ci_cd_analytics_releases
@vjain-gl, can you help me review this change? Thanks!
Miguel Rincon (d020013b) at 17 Mar 13:37
Move CI/CD projects dashboard files
... and 202 more commits
gitlab-org/gitlab!226740 (merged) seems to try to address this issue, but I suspect it was merged after this occurred. cc @trevorpierce
I have the following failure in our my pipelines: https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/13523412267