Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow integration with melos #396

Open
GZGavinZhao opened this issue Jun 20, 2022 · 7 comments
Open

Allow integration with melos #396

GZGavinZhao opened this issue Jun 20, 2022 · 7 comments

Comments

@GZGavinZhao
Copy link

GZGavinZhao commented Jun 20, 2022

melos is another tool for managing mono repos. However, I feel that mono_repo is better when generating readable/debuggable CI config in the least amount of typing. Therefore, we decided to use both melos and mono_repo for our repo.

This, unfortunately, poses a problem: melos needs to be dart pub global activate-d and ran melos bootstrap to link local packages using the pubspec_overrides.yaml file. If not, then analyzing and testing might fail. mono_repo provides no way of running arbitrary commands at the start of each CI job.

I hope we can either allow defining commands to be run at the start of each job, or add a melos config to mono_repo.yaml. When set to true, it will add a step to activate and bootstrap melos before any user-defined commands are run.

I have already implemented the second option in a basic way. If accepted I'd be glad to further polish it!

@kevmoo
Copy link
Collaborator

kevmoo commented Jun 21, 2022

I support better integration in principle. Figuring out the details is always fun, though.

CC @natebosch and @jakemac53

@jakemac53
Copy link
Collaborator

jakemac53 commented Jun 21, 2022

Personally I would suggest just creating your own script under tool, which invokes melos and then mono_repo?

If we did want to support something like this I would probably just support running arbitrary commands, we don't want to be picking up a dependency on the api of melos.

@natebosch
Copy link
Member

we don't want to be picking up a dependency on the api of melos.

+1

would #382 be sufficient to solve this use case?

@GZGavinZhao
Copy link
Author

@natebosch Yes, #382 would be sufficient.

@blaugold
Copy link

blaugold commented Jun 22, 2022

I'm not very familiar with mono_repo so I've created an example repo to better understand how to integrate it with Melos.

It's possible to get it working with Melos, but it's not great:

# a/mono_pkg.yaml
sdk:
  - stable

stages:
  - analyze:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart analyze'
  - format:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart format --output=none --set-exit-if-changed .'
  - test:
      - command:
          - 'dart pub global activate melos'
          - 'dart pub global run melos bootstrap --scope a'
          - 'dart test'

I don't think #382 would help all that much, since you would have to configure Melos for every job, if I understand the intent of the PR correctly.

It would be optimal, if there was a way to replace the pub upgrade step with an arbitrary command. Even better, if the command gets the name of the current package in an environment variable.

If this was configurable in mono_repo.yaml for all jobs, it would make it really simple to set up Melos.

@kevmoo
Copy link
Collaborator

kevmoo commented Jun 23, 2022

Yeah, having some template silly (like #382 ) would be nice. Not sure how much complexity we'd be adding...

@dnys1
Copy link

dnys1 commented Jul 22, 2022

Would it make sense to expose TaskType.beforeAllSteps/TaskType.afterEachSteps, maybe via mono_repo.yaml, similar to how on_completion is exposed? My use case could also benefit from the lack of repetition. Another option would be to define a custom action in the repo and use #382, but that would lead to nearly the same amount of repetition, I think.

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

No branches or pull requests

6 participants