Activates Melos for your GitHub workflow. It can also automatically version, dry-run and publish your packages to pub.dev.

NOTE: Remember to check the "Allow GitHub Actions to create and approve pull requests" checkbox in the bottom of the Actions > General section of your repository settings if you want to use create-pr: true.

The melos-action needs to have either dart or flutter on the path before it can activate melos. With this set up it will automatically add melos to your path and run melos bootstrap, for more advanced usa-cases, like automatic releases, see the Parameters section.

steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
- uses: bluefireteam/melos-action@v3

steps:
- uses: actions/checkout@v4
- uses: dart-lang/setup-dart@v1
- uses: bluefireteam/melos-action@v3

There are a few parameters that can be set to customize the behavior of the action, they are all optional.

To set a specific parameter you use the with keyword in your action, like in the example below.

steps:
  - uses: actions/checkout@v4
  - uses: subosito/flutter-action@v2
  - uses: bluefireteam/melos-action@v3
    with:
      run-bootstrap: false

You can set a version constraint for the melos version if you don't want the latest version (default).

Simply adding the version, like in the example below, will guarantee that exactly the specified version is activated.

You can also use all range constraints that exist for pub. For example '^1.0.0' would allow any version from 1.0.0 to 2.0.0 (but not including 2.0.0). If you want an even tighter restriction you can define the version like this '>=1.2.0 < 1.3.0' which would allow any version between 1.2.0 (included) to 1.3.0 (excluded).

steps:
- uses: actions/checkout@v4
- uses: subosito/flutter-action@v2
- uses: bluefireteam/melos-action@v3
  with:
    melos-version: '1.2.0'

It is recommended that you read through and follow the set-up steps at dart.dev before continuing, not applicable for dry-runs of course. Ensure that publishing from workflow_dispatch events is enabled:

Remember that if your package isn't already published to pub.dev you need to manually publish it the first time, after that you can use the action to automatically publish it.

If you want to semi-automatically release your packages for example when a new PR is merged you have a few different options:

1. Version and release on workflow dispatch: Create three actions: one which versions and dry-run publishes your packages and then creates a release preparation PR when this workflow is triggered. And a second action that creates a tag when the PR is merged. In a third action a manual dispatch workflow is created to publish the created tag to pub.dev.
2. Version and release on each PR: Create three actions: one which versions and dry-run publishes your packages and then creates a release preparation PR every time a PR from a contributor is merged. The other two are the same as in 1).
3. Only run dry-run versioning and publishing as a check: Only use the action to ensure in your pipeline that your packages are releasable, i.e. doesn't fail any dry run.

Note: Publishing directly from GitHub Actions to pub.dev only works if dispatched from a tag, not from a branch.

And this note is worth repeating - Remember to check the "Allow GitHub Actions to create and approve pull requests" checkbox in the bottom of the Actions > General section of your repository settings if you want to use create-pr: true.

See the examples directory to get files that you can copy and paste into your repository.