From Slack: > @clavimoniere: is there actually value to these automated update MRs? They are always trying to skip already-open existing update MRs from earlier versions and lead to situations like this: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218521#note_3005038510 > > These MRs require just as much manual work as if we just manually opened them in the first place, but without awareness of existing MRs in flight. > @trevorpierce: My hot take is no, because these automated helpers make it difficult to keep up when doing a manual migration into the monolith. I just shipped a significant major change to Pajamas and am working on the gitlab-ui integration as we speak. It would be a lot less stressful if I knew I wasn't playing beat the clock with a bot trying to be helpful. It's hard enough updating tests, dependency versions, and in this case, production code to use the new a11y API for the components I updated. > @markrian: > > > is there actually value to these automated update MRs > >Yes, because not every contribution to @gitlab/ui warrants the creation of an integration MR. > > In those cases, in order for gitlab-org/gitlab to receive timely bumps of @gitlab/ui, though only solution is automation. > > So, I don't think we should drop them. But, perhaps there are adjustments we could make. > > We could set [separateMajorMinor: false](https://docs.renovatebot.com/configuration-options/#separatemajorminor). > > Or, we could make major updates manual with [dependencyDashboardApproval: true](https://docs.renovatebot.com/configuration-options/#dependencydashboardapproval). > > I'm inclined to go with the first one. > @clavimoniere: I'm not sure separateMajorMinor would fix this. In this example, I think what it would mean is that the MR I just merged for a minor version would not have been automatically created, but the MR for the subsequent major release would have, right? in that case, the problem I linked to here would have still come up, as I would have opened a manual MR to upgrade to my minor version in the meantime so that I could resolve the test updates. > > _unless_ the idea here is that we purposefully wait until the major version and do all of these updates in the major version upgrade? > > We would also need to figure out what we want to do about successive major releases. Sounds like Trevor has a 128 release he's working on but 127 hasn't been updated in the monolith yet. would we want to prefer to skip the lower major version and do all of the necessary changes in the monolith for all of the major versions we're advancing past in a single MR in the monolith? > > I guess it could also be possible to do some traffic control within our repo -- what if we try to coordinate merging major update change MRs instead of merging them immediately when they're ready (assuming they're not an urgent fix)? ## Context - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/213217#note_2933654991 - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218521#note_3005856734 ## Proposal 1. [Make `publish_npm_packages` run in a scheduled pipeline only](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/5838). 1. [Enhance the changelog format](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/5793) to include the originating MR of the `@gitlab/ui` change, and its author. 1. [Automatically assign `@gitlab/ui` contributors](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/3953) as reviewers of Renovate MRs that bump `@gitlab/ui`. 1. [Set `separateMajorMinor: false`](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot/-/merge_requests/1453) in the Renovate config for `@gitlab/ui` updates to the monolith. 1. [Make it clearer that integration test MRs should never be merged](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/5795). Their only purpose is to draft pipeline fixes that can be cherry picked into Renovate MRs.