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

feat(filter-options): Allow command to continue if no packages are matched #2280

Merged
merged 3 commits into from Oct 15, 2019
Merged

feat(filter-options): Allow command to continue if no packages are matched #2280

merged 3 commits into from Oct 15, 2019

Conversation

debugmaster
Copy link
Contributor

@debugmaster debugmaster commented Sep 21, 2019

Description

  • Added new param continueIfNoMatch in filterPackages() to prevent an exception from being thrown if all filters did not match any package.
  • Added --continue-if-no-match as a Filter option to enable/disable new param.
  • Added documentation to the method and param. Because this option is hidden by design (because it is not really a filter), I'd like to hear what the reviewers may suggest.

Motivation and Context

My motivation is being able to execute the same command in one or more Lerna-managed mono repos, which may or may not contain the same scopes. As long as every team follows the definition of scopes, the same CI can be applied to every team.

For example:

lerna-repo-1/
  package.json
  team-a/
    lib-1/
      package.json
    service-1/
      package.json
  team-b/
    service-1/
      package.json
    service-2/
      package.json
lerna-repo-2/
  team-c/
    component-1/
      package.json
    lib-1/
      package.json
    service-1/
      package.json

The CI tries to create a scope like --scope <team>-<type-of-artifact>-*. With this new option, we don't need to conditionally select which artifacts to build. For example, building libs of Team B would fail in the current behavior.

Imagine also some people may have suggested adding empty packages only to bypass CI.

How Has This Been Tested?

I have added unit tests to cover the new param. They contain the same scenarios by the tests that throw the exception (plus the new param);

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@debugmaster
Copy link
Contributor Author

@evocateur how often Lerna has a round of reviews?

@JabbyPanda
Copy link

continue-if-no-match flag name is such not obvious name to memorize, --allow-empty-scope would be better choice, IMHO

@debugmaster
Copy link
Contributor Author

I agree that it is not a trivial name, but does it require to be memorized? This is not meant to be necessary all the time. That's why I decided to go with a more explanatory flag.

Regarding your suggestion, --allow-empty-scope seems ambiguous to me because of the parameter --scope. Of course, this is a matter of stating to the user what is expected when used.

Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

The code looks fine, but I'm not especially inclined to allow something like this, as I believe filters that rule out all available packages should always error.

The desire to filter in the manner you describe, to me, is an indication that you've got too many packages in your monorepo.

@debugmaster
Copy link
Contributor Author

@evocateur They are different monorepos with the same CICD pipeline.

As I mentioned, the process is generic to allow any type of artifact to be built, tested and published, but the artifacts vary by team. That's why using filters can't fail for this case.

Is it possible to count the number of matches without failing? If I am able to retrieve this info, I may skip or continue a pipeline step.

Copy link
Member

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

I changed my mind, it's hidden anyway, and it has good tests. Thanks for your patience.

@evocateur evocateur changed the title Allow command to continue if filters do not match any package. feat(filter-options): Allow command to continue if no packages are matched Oct 15, 2019
@evocateur evocateur merged commit a706023 into lerna:master Oct 15, 2019
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.

None yet

3 participants