# Description
The docs site build was triggered on every push to `main`, causing
unnecessary rebuilds. This PR moves the docs dispatch trigger into a
dedicated `docs.yml` workflow that only runs when:
- Files in `doc/**` change on `main`
- A new `v*` tag is created
The examples gh-pages deployment in `gh-pages.yml` remains unchanged.
## Checklist
- [x] I have followed the [Contributor Guide] when preparing my PR.
- [-] I have updated/added tests for ALL new/updated/fixed
functionality.
- [-] I have updated/added relevant documentation in `docs` and added
dartdoc comments with `///`.
- [-] I have updated/added relevant examples in `examples` or `docs`.
## Breaking Change?
- [ ] Yes, this PR is a breaking change.
- [x] No, this PR is not a breaking change.
## Related Issues
[Contributor Guide]:
https://github.com/flame-engine/flame/blob/main/CONTRIBUTING.md
[Conventional Commit]: https://conventionalcommits.org
[CHANGELOG]:
https://github.com/flame-engine/flame/blob/main/CHANGELOG.md
Adds a new step to the `release-tag.yml` workflow that automatically:
1. Creates a short `v{version}` tag (e.g. `v1.36.0`) pointing at the
same commit as the melos-generated `flame-v{version}` tag
2. Creates a GitHub release with the flame package changelog as release
notes
This removes the manual step of creating the `v` tag and GitHub release
after each flame release.
Bump the Flutter and dartdoc version so that we can develop with the new
Flutter version.
This aggressive bump is due to Flutter bumping dartdoc to 9.0.0.
Update cspell used on CI to latest version `9.2.1`:
https://www.npmjs.com/package/cspell
Note that the contributing guidelines does not mandate a version, so
this (the latest) will be installed if following those instructions.
* The root package should be named `_` in pub workspaces that doesn't
have an actual app or package in the root.
* Melos needs to be updated to support this.
* The flame_3d example should be named flame_3d_example to follow the
convention.
Add very basic benchmark infrastructure, using the `examples` app as a
centralized benchmark playground and with first ever benchmark file just
testing some components and updates (more to come).
This also sets up the `dart-benchmark-action` to run, starting on this
very PR!
Updates to use the new color method `withValues`.
---------
Co-authored-by: Lukas Klingsbo <lukas.klingsbo@gmail.com>
Co-authored-by: Jochum van der Ploeg <jochum@vdploeg.net>
With this PR we'll be able to publish by running an action from the
Actions tab which will create a release PR that we can review and when
that PR is merged it will tag all new packages and trigger release
workflows for them.
The script has two purposes:
remove orphan words
alphabetize the files
I set it up to run on GitHub action as a checker, but a --fix option is available as well for running locally.
When running, I noticed that there are A LOT of orphaned words.
At first, I thought that it might be the case that cSpell was missing words on our docs that were clearly used, which would be a HUGE issue. I made this PR to validate that: #2735
But upon proper investigation, and using cSpell's trace command, I realized that we import multiple standard dictionaries: "en_US" and "softwareTerms", and they are constantly being updated. The word "cypher" was just added 12 hours ago, for example.
Turns out ALL of the current orphan words are properly being detected on our files, but now are included on the official dictionaries! Which is amazing.
Note that I did have to stop using the GitHub Action to run cSpell. The reason is twofold; (1) because I need to install cSpell anyway to run my script and didn't want to have the action download it again; and (2) because the version on the GitHub Action (even though it is the same 7.3.7 from npm that I have locally) doesn't have the latest updates (like does not have the cypher word that was added 12h ago). This would make my script and the CI script incompatible.
The issue with GitHub killing out test pipeline might be due to the running on the latest ubuntu image, this commit tries to use the older one (which I read could be a solution somewhere...)
This is a first step towards enabling DCM for Flame. Though I have tested with all rules, and am working on selecting, assessing, and fixing violations, as a first step, we can merge the infrastructural changes to flame_lint to and GitHub actions.
As a proof of concept, I am enabling two rules for which we have no violations.
I will followup with enabling more rules, adding discussions for controversial changes, and fixing non-controversial violations.
This PR migrates us to the prerelease version of Melos (3.0.0-dev.0) and our pipelines to Flutter 3.7.1
It's a golden opportunity for us to test the upcoming version of melos and give them any feedback that we might have. :)
The migration instructions can be read here:
https://melos.invertase.dev/guides/migrations
I am on a crusade to improve our spellchecking. I have a big PR that I am now going to break down into very small chunks to for review.
zwaldowski's cspell-action has been deprecated in favor of streetsidesoftware/cspell-action.
This PR:
updates to use the new recommended cspell action
update to use checkout v3, because why not
fixes a few violations the new action caught
Note: I think we should make a distinction between things that should be in a dictionary (e.g. AABB, a standard industry acronym that we expect people to know what it is) and specific edge-cases/ignore rules for specific parts of specific files (e.g. something like fccc which is meaningless outside of the very specific context in which it is used). For the latter, I believe we should use case-by case exceptions.
