Keeping project dependencies up-to-date is a challenging problem. Services like GitHub’s automated dependency updating system, Dependabot, go a long way to help make things easier, but that is only helpful if your package manager’s ecosystem is supported. In the case of Scala based projects, it is not.
Enter Scala Steward.
Scala Steward provides a similar, low-effort way to keep project dependencies up-to-date. You simply open a pull request against the Scala Steward repository and add a reference to your project’s GitHub repository inside of a specially designated Markdown file. After that, Scala Steward (which manifests itself as a robot user on GitHub) keeps your project dependencies up-to-date via pull requests.
Unfortunately, this easy-mode option requires that your repository be publicly accessible. There are options for running Scala Steward as a service for yourself, but that path is less trodden and requires a bit more effort.
Scala Steward and GitHub Actions
So what other options do you have if your Scala project is inside a private repository? Well, if your project is on GitHub, then you likely have access to their workflow automation service, GitHub Actions. Scala Steward’s maintainers created a GitHub Action that lowers the bar to adding Scala Steward support to projects via the GitHub Actions execution model.
By default, the Action supports dependency detection through a workflow defined inside of your project’s repository. This approach makes it easy to simulate the public instance of Scala Steward on a per repository basis. But, there is also a centralized mode that allows you to mimic the way the centrally managed instance of Scala Steward works.
This centralized mode gives us an opportunity to have the best of both worlds: a low-effort way to keep multiple project dependencies up-to-date (similar to the public instance of Scala Steward), and the ability to do so across both public and private repositories!
Putting things together
First, create a GitHub repository for your instance of Scala Steward and put a file in it at .github/workflows/scala-steward.yml
with the following contents:
name: Scala Steward
on:
schedule:
# Schedule to run every Sunday @ 12PM UTC. Replace this with
# whatever seems appropriate to you.
- cron: "0 0 * * 0"
# Provide support for manually triggering the workflow via GitHub.
workflow_dispatch:
jobs:
scala-steward:
name: scala-steward
runs-on: ubuntu-latest
steps:
# This is necessary to ensure that the most up-to-date version of
# REPOSITORIES.md is used.
- uses: actions/checkout@v2
- name: Execute Scala Steward
uses: scala-steward-org/scala-steward-action@vX.Y.Z
with:
# A GitHub personal access token tied to a user that will create
# pull requests against your projects to update dependencies. More
# on this under the YAML snippet.
github-token: ${{ secrets.SCALA_STEWARD_GITHUB_TOKEN }}
# A Markdown file with a literal Markdown list of repositories
# Scala Steward should monitor.
repos-file: REPOSITORIES.md
author-email: scala-steward@users.noreply.github.com
author-name: Scala Steward
Hopefully, the inline comments help minimize any ambiguity in the GitHub Actions workflow configuration file. For completeness, below is an example of the Markdown file as well:
- organization/repository1
- organization/repository2
- organization/repository3
The last step is to ensure that any private repositories add the user associated with the GitHub personal access token as a collaborator with the Write role permissions. Also, to slightly improve usability and maintainability, consider the following suggestions:
- Add Dependabot support to your Scala Steward repository to keep the Scala Steward GitHub Action up-to-date.
- Avoid tying Scala Steward to an individual user GitHub account. Consider creating a bot account first, then create a personal access token with it to use with Scala Steward.
- Create a custom Scala Steward team (e.g., @organization/scala-steward ) and add the bot account above to it. Now, instead of remembering to add the bot account to your Scala project repository as a collaborator, you can add the more intuitive Scala Steward team.
Top comments (0)