⚠️ DISCLAIMER ⚠️: this way of using dependabot with the workflows is working on the time of writing and might not be the intended way of github to be used.

What happens normally?

If you enable Dependabot in your GitHub repo and/or define a dependabot.yml in your .github folder of your repository, you define the way you want to work with dependabot.
Github will then have dependabot check your repository for potential package updates. This is mainly for security patches of packages.
You can also use this way to update packages the way you like.
You are then prompted with pull requests, created by dependabot of your various dependencies. We would like to automate this process as much as possible, so minor versions can just pass and become part of the main process.

Auto-approve / Auto merge might release your dependabot changes

If you have auto-merge enabled and an auto-approve of dependabot items auto-approve of dependabot items, you might have noticed dependabot also triggering your main workflow. This can trigger unintended deployments/releases.

Using Dependabot on a separate branch

To have dependabot be part of the workflow, without bothering you too much, you can 'use' a setting of having dependabot be ran on a seperate branch, which is pointed out in the documentation here: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#target-branch , which shows the following example:

# Specify a non-default branch for pull requests for pip

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise pull requests for version updates
    # to pip against the `develop` branch
    target-branch: "develop"
    # Labels on pull requests for version updates only
    labels:
      - "pip dependencies"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates on Sundays
      day: "sunday"
    # Labels on pull requests for security and version updates
    labels:
      - "npm dependencies"

Leveraging the Target-Branch Setting

What I noticed is, that if you set this target-branch option to the default branch of your repository, triggers of main workflows will NOT trigger.

Conclusion

That means, that this unintentional working of the target-branch setting in dependabot can be used to have your cake and eat it too: have the dependabot packages be updated and not trigger any default branch workflow.

Let me know if you have any questions or feedback.