subosito / flutter-action

Flutter environment for use in GitHub Actions. It works on Linux, Windows, and macOS.
MIT License
2.16k stars 191 forks source link

Add support for Flutter version ranges #299

Open bartekpacia opened 2 months ago

bartekpacia commented 2 months ago

As a plugin maintainer, I want to run my CI to test/analyze/format my plugin against Flutter version it supports.

For example, let's say my plugin supports at least Flutter 3.10.0, so I'll have this in pubspec.yaml:

environment:
  sdk: ">=3.0.0 <4.0.0"
  flutter: ">=3.10.0"

In my GitHub Actions, I have this:

jobs:
  main:
    name: Flutter ${{ matrix.flutter-version }}
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        flutter-version: ["3.10.x", "3.13.x", "3.16.x", "3.19.x"]

    steps:
      - name: Clone repository
        uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable
          flutter-version: ${{ matrix.flutter-version }}

Problems with it:

Idea

I suggest addition of flutter-version-range and flutter-version-range-file property:

- name: Set up Flutter
  uses: subosito/flutter-action@v2
  with:
    channel: stable
    flutter-version-range-file: pubspec.yaml # path to pubspec.yaml

Assuming the pubspec.yaml defined above, this would return [3.10.6, 3.13.9, 3.16.9, 3.19.5] (latest PATCH versions for every MINOR version).

Except it wouldn't work, because then we only know the versions at runtime, but to make a matrix build we need to known them statically.

It would also increase complexity of this action.


For now, I think the best action forward is to create a script (either Sh/Bash or Dart - the second would be likely much better because the pub_semver package could be used). Then this script could be wrapped into an new GitHub Action targeted mainly at package/plugin authors.

Then the CI workflow from above could be split into 2 jobs: