remove the self_validate step from the mono_repo config

[devoncarew]

• remove the self_validate step from the mono-repo config - as its currently implemented, it will cause dependebot dep bump PRs to fail

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Many Dart repos have a weekly cadence for reviewing PRs - please allow for a week or two of latency for initial review feedback.

---

[jakemac53]

Imo this check provides more value than problems - yes it means we can't merge dependabot PRs but it has saved me numerous times from forgetting to regenerate the config.

[devoncarew]

Imo this check provides more value than problems - yes it means we can't merge dependabot PRs but it has saved me numerous times from forgetting to regenerate the config.

I'd like to figure out a way where we can have both; I opened google/mono_repo.dart#451 to track that. Updating mono_repo w/ a fix is one possibility.

We could also turn off dependabot for those repos using mono_repo that want to keep the mono_repo verification step. Updating the dependabot config to open-pull-requests-limit: 0 will disable PRs for everything but security related ones.

Or we could have a weekly / monthly cron job which does a pub global activate to the latest mono_repo, re-generates the mono_repo files, and fails if there's any changes to the repo.

[jakemac53]

I'd like to figure out a way where we can have both; I opened google/mono_repo.dart#451 to track that. Updating mono_repo w/ a fix is one possibility.

Yeah, I do agree we either want both working well together or we want to disable one (but I have a very strong bias towards disabling dependabot).

We could also turn off dependabot for those repos using mono_repo that want to keep the mono_repo verification step. Updating the dependabot config to open-pull-requests-limit: 0 will disable PRs for everything but security related ones.

Can we disable it only for certain workflows? I would be fine with disabling it for the mono_repo workflow but leaving it enabled for the hand written ones.

Or we could have a weekly / monthly cron job which does a pub global activate to the latest mono_repo, re-generates the mono_repo files, and fails if there's any changes to the repo.

I like the idea of disabling dependabot for the mono_repo workflows combined with this option - that way when mono_repo does update its deps we will get a notification to update. Possibly it could automatically send a PR eventually like dependabot does.

Then mono_repo is managing the versions but they get kept up to date with those versions in all the repos.

[devoncarew]

Can we disable it only for certain workflows? I would be fine with disabling it for the mono_repo workflow but leaving it enabled for the hand written ones.

It doesn't look like you can ignore specific files:

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

Just opt-in directories, and ignore specific deps to not update (like specific actions).

I like the idea of disabling dependabot for the mono_repo workflows combined with this option - that way when mono_repo does update its deps we will get a notification to update. Possibly it could automatically send a PR eventually like dependabot does.

It looks like we can't ignore specific files, so we'd be ignoring all workflow files. This would probably not be a better place to be - the non-mono_repo workflow files would just accrue tech debt / older action versions.

I'll close this - we can look into reviving google/mono_repo.dart#420.