You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can already use Dependabot Version Updates for keeping marketplace actions (in addition to internal/private actions) up to date. However, did you know we can use Dependabot for keeping Reusable Workflows up to date as well?
Authorization Options
If you are referring to reusable workflows that are public, the implementation is easy. More likely though, especially if you're in an organization creating reusable workflows to standardize on CI/CD practices, you are going to be working with non-public repositories containing your reusable workflows.
There are two ways that you can configure Dependabot when working with resources in internal or private repositories. To summarize, you can either:
This setting requires organization admin permissions to access
Unfortunately, there isn't an API to automate this process, it has to be done within the UI
Create a Dependabot secret
If you plan to create a large number repositories that you want to be a source for Dependabot, creating a Dependabot secret (preferably as an org-level Dependabot secret) with the value of a personal access token (preferably a fine-grained token) that has read-access to the required repositories would be preferred
I don't find it as detrimental to use a personal access token as a Dependabot secret since Dependabot secrets can only be accessed by Dependabot; you can't use a GitHub Actions workflow to expose the secret accidentally/intentionally
The only concern would be updating the token if it expires, is revoked, or the original author doesn't have access to the repo(s) anymore
Tip
If you only have a few, and rarely increasing set of repositories for custom actions / reusable workflows, I recommend the first approach.
If you have a large number of repositories and/or are creating many new repositories for actions / reusable workflows, the second approach scales better.
Configurations
Approach 1: Grant Access to Dependabot in the UI
For the first approach (authorizing Dependabot access manually), the YML configuration is no different than if you were using Dependabot to keep marketplace actions up to date.
version: 2updates:
- package-ecosystem: "github-actions"directory: "/"# Workflow files stored in the default location of `.github/workflows`schedule:
interval: "daily"open-pull-requests-limit: 5
Once you grant Dependabot access to the repository, you will see it show up in organization settings –> Code security and analysis –> Grant Dependabot access to private repositories. Additional repositories can be added here:
Approach 2: Using a Dependabot Secret
For the second option (using a Dependabot secret), you will need to add the registries property to the YML configuration. The registries will reference type: git and use a Dependabot Secret (preferably an org-level Dependabot secret):
version: 2updates:
- package-ecosystem: "github-actions"directory: "/"# Workflow files stored in the default location of `.github/workflows`schedule:
interval: "daily"registries:
- githubregistries:
github:
type: giturl: https://github.comusername: x-access-token # username doesn't matterpassword: ${{ secrets.MY_DEPENDABOT_SECRET }} # the dependabot secret you created
Note
You can create a Dependabot secret at the organization level or repository level.
Results
If things are working properly, you should see a successful run in your Dependabot run logs:
And if there is a new semver version of a reusable workflow, you should see a Dependabot-created pull request:
Tip
Pro-tip: You can reply @dependabot merge or @dependabot squash and merge (among other commands) to tell Dependabot to merge the pull request.
Summary
Now we can create and properly version reusable workflows AND have our downstream users automatically be notified of version updates. This helps a ton in making it front and center for developers that there's an update they need to look at! 🎉
ActionsBuild, test, and automate your deployment pipeline with world-class CI/CDDependabotBest PracticesBest practices, tips & tricks, and articles from GitHub and its users
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Overview
We can already use Dependabot Version Updates for keeping marketplace actions (in addition to internal/private actions) up to date. However, did you know we can use Dependabot for keeping Reusable Workflows up to date as well?
Authorization Options
If you are referring to reusable workflows that are public, the implementation is easy. More likely though, especially if you're in an organization creating reusable workflows to standardize on CI/CD practices, you are going to be working with non-public repositories containing your reusable workflows.
There are two ways that you can configure Dependabot when working with resources in internal or private repositories. To summarize, you can either:
Tip
Configurations
Approach 1: Grant Access to Dependabot in the UI
For the first approach (authorizing Dependabot access manually), the YML configuration is no different than if you were using Dependabot to keep marketplace actions up to date.
You will then have to check your Dependabot run logs to authorize Dependabot for that repository (or add it via the organization settings):
Once you grant Dependabot access to the repository, you will see it show up in organization settings –> Code security and analysis –> Grant Dependabot access to private repositories. Additional repositories can be added here:
Approach 2: Using a Dependabot Secret
For the second option (using a Dependabot secret), you will need to add the
registries
property to the YML configuration. Theregistries
will referencetype: git
and use a Dependabot Secret (preferably an org-level Dependabot secret):Note
You can create a Dependabot secret at the organization level or repository level.
Results
If things are working properly, you should see a successful run in your Dependabot run logs:
And if there is a new semver version of a reusable workflow, you should see a Dependabot-created pull request:
Tip
Pro-tip: You can reply
@dependabot merge
or@dependabot squash and merge
(among other commands) to tell Dependabot to merge the pull request.Summary
Now we can create and properly version reusable workflows AND have our downstream users automatically be notified of version updates. This helps a ton in making it front and center for developers that there's an update they need to look at! 🎉
Beta Was this translation helpful? Give feedback.
All reactions