Generalize publishing GitHub Action to support flutter

[guidezpl]

The action to publish packages doesn't work for Flutter packages due to the following error.

Run dart pub get
  dart pub get
  shell: /usr/bin/bash -e {0}
  env:
    PUB_CACHE: /home/runner/.pub-cache
    DART_HOME: /opt/hostedtoolcache/dart-sdk
    PUB_TOKEN: ***
Resolving dependencies...
Because google_fonts requires the Flutter SDK, version solving failed.

https://github.com/material-foundation/flutter-packages/actions/runs/4079639516/jobs/7031216899

Can this action be generalized or another one published for Flutter?

[guidezpl]

@devoncarew is dart pub get required?

[bartekpacia]

I had the same/similar problem after updating to Flutter 3.7.

Something has changed and while previously dart pub publish could be used to publish Flutter packages, it doesn't work anymore. I migrated my package to use flutter pub publish to fix the problem.

[jonasfj]

@sigurdm, I think the fact that we patched dart pub publish to do dart analyze and implicit dart pub get, cause the regression that @bartekpacia mentioned.

On topic, I think it would be great if the reusable-workflow could be used to publish flutter packages with:
https://github.com/dart-lang/setup-dart/blob/main/.github/workflows/publish.yml

I really would love to recommend that people use the reusable workflow as it'll let us patch the workflow after they've adopted it. So in theory we could potentially add SLSA support in the future.

---

@sigurdm, any ideas? should we extend the reusable-workflow to install Flutter, when there is an SDK dependency on Flutter?

I'm not keep on patching the community maintained flutter-action repository to have reusable-workflow, because we would be unable to trust such a workflow on pub.dev -- should ever want to do thing that requires trust -- like inspecting github APIs to check if branch protection is enabled, etc, stuff that SLSA does.

[sigurdm]

should we extend the reusable-workflow to install Flutter, when there is an SDK dependency on Flutter?

I don't currently see other good ways to go around this. The only alternative would be to disable the resolution in the publish-step (as we cannot resolve against sdk dependencies without the sdk).

[jonasfj]

@sigurdm, we could consider having a dart pub publish --skip-validation thing.

In practice, if you're publishing with automation, you really should put all of your unit tests ahead of the actual publishing step..

Or we should make the custom workflow install Flutter, I'm not sure if that'd be a huge issue.
It's just downloading and extracting the Flutter SDK. We don't have to make setup-dart do that in general, just .github/workflows/publish.yml

[devoncarew]

I think it's a bit non-intuitive to have the setup-dart action install a flutter sdk. Is there some way to compose this with the existing actions which install a flutter sdk?

[devoncarew]

We don't have to make setup-dart do that in general, just .github/workflows/publish.yml

Perhaps having a separate .github/workflows/publish-flutter.yml script might be enough of an indication that this could install flutter specific bits.

[sigurdm]

Why doesn't setup-dart know how to setup flutter?

[sigurdm]

We discussed this a bit on the weekly pub-meeting.
I think from the pub side of things:

• we would prefer a single workflow for publishing (to avoid confusion and differences sneaking in)
• we don't want to implement a pub publish --ignore-warnings (that would lead to broken publications) -> we actually need to install flutter
• we don't want to run community code (not clear that flutter-actions will always do the right thing)

So that looks like having a dash-team script that can download and install Flutter is needed.

• We think it would be enough to default to latest stable, with a manual parameter for the channel and version.
• This can probably be done with a curl and tar invocation.
• If we install Flutter, we might not need to install the Dart SDK, but can use the one embedded in a flutter-sdk (this might seem like a premature optimization, but otherwise we get the question of choosing the right sdk for publishing a package).

[jonasfj]

we don't want to run community code (not clear that flutter-actions will always do the right thing)

More importantly, it'll be hard to do SLSA in the future.

we would prefer a single workflow for publishing (to avoid confusion and differences sneaking in)

If we decided to do a github.com/flutter/setup-flutter repository, then perhaps it wouldn't be bad to put the logic in there..

Otherwise, perhaps it's find if we just extend publish.yml to support Flutter, whether we always download Flutter or not won't matter much -- in practice this only runs with publishing, which shouldn't be frequent.

[guidezpl]

Otherwise, perhaps it's find if we just extend publish.yml to support Flutter, whether we always download Flutter or not won't matter much -- in practice this only runs with publishing, which shouldn't be frequent.

+1. If there ever is a flutter/setup-flutter repo and publishing workflow, its workflow could simply depend on publish.yml.

[bartekpacia]

I'd like to add that flutter pub publish doesn't play well with Automated Publishing with GitHub Actions on pub.dev.

The most widely used subosito/flutter-action doesn't support pulling the pub.dev token, so doing flutter pub publish fails on CI.

The result is that I have to use dart-lang/setup-dart, and then subosito/flutter-action to be able to use flutter pub publish.

See this commit for an example of how I fixed it.

Not a good experience, if you ask me.

[devoncarew]

we might not need to install the Dart SDK, but can use the one embedded in a flutter-sdk

Keep in mind that the dart: APIs supported by the regular Dart SDK, and the Dart SDK vended into the Flutter SDK, are not the same. The Flutter version of the Dart SDK adds dart:ui and removes dart:mirrors (and several web core libraries). You can use the one to do publishing for the other, as long as you don't want to do something like run static analysis.

The main issue is that dart pub publish now wants to run static analysis as part of publishing validation? It may be worth considering making that portion of the checks opt-in (e.g., dart pub publish --run-analysis-checks).