Package lock auto update

[tjenkinson]

I realise there's no issue in the Backlog milestone for this. If it's also required for CI changes I can create one or just close this

I noticed in #40146 you added the package-lock and also the action to update it daily.

This PR configures dependabot to automatically open PRs for dependency updates. It then also adds an auto merge action (disclaimer: I wrote this) and configures it to automatically merge PR's that are created by dependabot when the required status checks pass. I'd suggest making some of the checks required so that the merge is blocked if it causes build/test failures.

I think this approach is slightly better than the existing update-package-lock workflow because having the update opened on a PR means all the (required) pr checks run, and need to go green before the update is merged, so it means if there is a dependency update that contains a breaking change, it might be caught before it hits devs, and it highlighted in a PR.

Let me know what you think

[orta]

Thanks, but we already have a working setup for updating our package lock on a weekly basis automatically.

IMO we probably don't want it, this repo is busy enough without all the additional noise that dependabot would add.

[tjenkinson]

@orta fair enough. Ideally there would be no noise from this like your current solution, except when there are failures, but I don't think it's possible to filter notifications on GitHub PR's like that. Could probably set up an email filter but it's not ideal.

[tjenkinson]

Actually looks like it would be possible to set up email filters based on the user

[DanielRosenwasser]

Unless @amcasey has a specific preference here, I think we'd prefer to have fewer automated PRs in general. It's not as much about notifications, though we'd rather not have to configure that either.

[amcasey]

Not having either user or automated review of these changes was an explicit goal - we wanted to maintain the behavior we used to have with latest, but leave ourselves a breadcrumb for being able to build each commit in the future.

It looks like good thought and work went into this but, unfortunately, I'd have to agree that isn't something we'd be interested in right now. Thanks though!