⚠️ 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.
Top comments (0)