Skip to content

Conversation

devoncarew
Copy link
Collaborator

  • refactor the repo's CI setup - prefer small, per-package workflow files to using mono_repo
  • refactor the analysis options files - move to using per-package files
  • update the config for the publishing workflow (allow workflow feedback from forks)

Copy link
Member

@osa1 osa1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the problem with mono_repo? I liked that the mono_repo configs are short (at least for what we do in this library) and I don't have to review and test generated YAMLs as they're generated and I can trust that mono_repo is well tested.

update the config for the publishing workflow (allow workflow feedback from forks)

What is "workflow feedback from forks"?

Regarding lints: I think it would be good to be in sync with the g3 version rather than Flutter (or any other) lints as at this point this library is more actively developed in g3 than here.

@devoncarew
Copy link
Collaborator Author

What is the problem with mono_repo? I liked that the mono_repo configs are short (at least for what we do in this library) and I don't have to review and test generated YAMLs as they're generated and I can trust that mono_repo is well tested.

I'm not a fan of the abstraction over github workflow files; it may have been a useful abstraction over travis configs but I don't think adds real value over using straight github workflow files. But if you're happy w/ the setup for this repo I won't push for changing it.

update the config for the publishing workflow (allow workflow feedback from forks)

What is "workflow feedback from forks"?

The publish pre-check workflow can only provide feedback for PRs from this repo - it can't write comments to PRs coming from forks of the repo. This updated config allows us to see the results of the publish workflow from PRs from forks as well.

Regarding lints: I think it would be good to be in sync with the g3 version rather than Flutter (or any other) lints as at this point this library is more actively developed in g3 than here.

We no longer have a lint set that represents what's used internally (pedantic was that set a while ago). dart_flutter_team_lints may be the closest, with some additional knobs tightened.

@devoncarew
Copy link
Collaborator Author

(closing in favor of more specific PRs: #960, #961, #962)

@devoncarew devoncarew closed this Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants