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
Whenever I bump the minimum Flutter version, I have to also remove it from CI workflow
Whenever a new Flutter version is released, I need to remember to add it to CI workflow
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:
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
:In my GitHub Actions, I have this:
Problems with it:
Idea
I suggest addition of
flutter-version-range
andflutter-version-range-file
property: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:
job get_flutter_versions
, outputs[3.10.6, 3.13.9, 3.16.9, 3.19.5]
job main
, gets the versions as input and uses them to create a matrix buildThe text was updated successfully, but these errors were encountered: