Automate Flutter package upgrades with GitHub Actions(a Dependabot alternative)

Like with pretty much any other framework, keeping up with package upgrades in Flutter can get pretty tedious. I decided to see if I could make things a little less tedious over the weekend and I'd like to share a GitHub Action workflow that I came up with while experimenting.

What about Dependabot?

I'd actually be happy to use Dependabot but there isn't full support yet. Somebody is working on it at the moment though. I'm confident there will be full support one day, it's just a matter of time. For now though Dependabot isn't really a realistic option.

Using GitHub Actions

There was the option of creating an Action and putting it on the Actions Marketplace but I'm not entirely sure what that would involve yet and I'm not that committed to the idea yet either considering that there is work being done on the Dependabot front. So in the end I just decided to create a workflow with existing Marketplace Actions. Here's roughly the set of steps I wanted the workflow to use:

1. Check out the repo
2. Pull in cache data(so the next step runs a little faster)
3. Setup Flutter CLI so it can be used in the next steps
4. Run flutter pub upgrade --major-versions
5. Run flutter pub get
6. Run flutter test
7. (Optional) Capture the output of flutter pub outdated for later
8. If there are changes from (4) commit them to a new branch and open a PR

And obviously I'd want this workflow to run every so often so it would need to be scheduled with cron. In the end this is what I came up with:

Copycopy code to clipboard
1name: Upgrade packages
2
3on:
4  workflow_dispatch:
5  schedule:
6    - cron: "0 0 * * *"
7
8env:
9  flutter_version: "2.2.2"
10
11# A workflow run is made up of one or more jobs that can run sequentially or in parallel
12jobs:
13  upgrade_packages:
14    # The type of runner that the job will run on
15    runs-on: ubuntu-latest
16
17    # Steps represent a sequence of tasks that will be executed as part of the job
18    steps:
19      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
20      - uses: actions/checkout@v2
21      - name: Cache Flutter dependencies
22        uses: actions/cache@v2
23        with:
24          path: /opt/hostedtoolcache/flutter
25          key: ${{ runner.OS }}-flutter-install-cache-${{ env.flutter_version }}
26      # Installs Flutter
27      - uses: subosito/flutter-action@v1
28        with:
29          flutter-version: ${{ env.flutter_version }}
30          channel: stable
31      # Upgrade packages(bump major versions)
32      - name: Run upgrade
33        run: flutter pub upgrade --major-versions
34      # Get/install packages
35      - name: Run get
36        run: flutter pub get
37      # Run tests
38      - name: Run tests
39        run: flutter test
40      # Captures the output of `flutter pub outdated`
41      - name: Check remaining outdated packages
42        id: check_outdated
43        run: |
44          content="$(flutter pub outdated)"
45          content="${content//'%'/'%25'}"
46          content="${content//$'\n'/'%0A'}"
47          content="${content//$'\r'/'%0D'}"
48          echo "::set-output name=outdated_info::$content"
49      # Opens a pull request with changes
50      - name: Create Pull Request
51        uses: peter-evans/create-pull-request@v3
52        with:
53          token: ${{ secrets.PAT }}
54          commit-message: Upgrade packages
55          title: Upgrade packages
56          body: |
57            Output for outdated check following upgrades:
58            ```
59            ${{ steps.check_outdated.outputs.outdated_info }}
60            ```
61          branch: feature/update-packages

For this to work you need to generate a Personal Access Token in your GitHub account's settings and then add that as a secret to your repository. You can learn more about this here. This is what the ${{ secrets.PAT }} value represents in the last step.

You might have also noticed that I have this set to run everyday at 12am UTC. I'm going to tweak this later on but like I said I'm just experimenting with things at the moment and want to see if I run into any issues down the road. If I find some improvements I can make I will update this post. If you wanted to run this on a weekly schedule instead, you could use something like "0 0 * * Sun" instead(12am UTC every Sunday).

Caveats

The above workflow has been working pretty good for me for the last few days on some simple, small projects. That being said it is far from perfect.

First of all the above workflow won't upgrade your Pods on the iOS side of things. If you switch from ubuntu-latest to macos-latest you could run pod install --repo-update in the ios directory of your project, I did try this out personally and it seemed to work okay - but keep in mind that workflows that use MacOS cost something like 10 times more than workflows that use Ubuntu. This would probably matter less if you were only running the workflow once a week or something like that.

Another thing you could tweak is the flutter pub upgrade --major-versions command. This command will potentially pull in breaking changes because it will upgrade over major versions. You can opt out of this behaviour by just running flutter pub upgrade instead.

One more shortcoming of the workflow above is that it only runs your tests. Your tests might not cover everything so adding a flutter build ios or flutter build apk might add an extra layer of security if the upgrades break your project. I think I'm going to look into all of these points as I keep tweaking the workflow.

Summing up

Like I said the workflow I introduced above definitely isn't perfect but I think that it's a good start and something that can be used to keep sane while we all wait for Dependabot support. If you're interested in more Flutter tips, I wrote another post about adding linting to a project a couple of days ago - you can find it here.