ci(release): update release process

[smallTrogdor]

Proposed changes

Simplify the release process

closes #44

Checklist

Before creating a PR, run through this checklist and mark each as complete:

• I have read the CONTRIBUTING document
• If applicable, I have added tests that prove my fix is effective or that my feature works
• If applicable, I have checked that any relevant tests pass after adding my changes
• I have updated any relevant documentation

[josxha]

Hi Nico, I just happened to come across this pr. It could be that triggering a release with workflow_dispatch will be blocked by pub.dev.

Pub.dev only allows automated publishing from GitHub Actions when the workflow is triggered by pushing a git tag to GitHub. Pub.dev rejects publishing from GitHub Actions triggered without a tag. This ensures that new versions cannot be published by events that should never trigger publishing.

See https://dart.dev/tools/pub/automated-publishing#publishing-packages-using-github-actions

P.S. Awesome work you're doing for the SBB!

[smallTrogdor]

Hi @josxha

glad to have you peeking in here ;)
and have you review some of my work (I really do mean that!). Maybe you now understand some more of my comments in previous issues (e.g. maplibre/flutter-maplibre-gl#436). And you might understand why I am very much excited for the iOS part of https://github.com/josxha/flutter-maplibre !

There's a couple of applications using this package by now :)

To your comment. Yes, I need to improve upon the CI / CD part for sure. I found this for the workflow_dispatch trigger type and publishing to pub dev: dart-lang/pub-dev#7177 (comment)

So I guess I will change this action to checkout a tag ref first (the one selected). The other option is that I directly trigger using the

on:
  push:
    tags:

style, but having a Github App do the Release Please part. Otherwise, the merge of the outstanding PRs from Release Please will not do anything (not triggering subsequent workflows).

[smallTrogdor]

And one more remark: all of this is only possible because some random people did some things in their free time 😉
so the real credits of SBB should go towards small OpenSource projects and contributors (like you!)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud