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

Do not comment on some PRs, based on private packages or changed path? #39

Open
FredKSchott opened this issue Aug 6, 2021 · 3 comments

Comments

@FredKSchott
Copy link

Hello! We're using changeset for Astro and are loving it so far. However, we have some workspace "packages" that aren't really packages. The docs site, the www homepage, and some example directories are all included in our workspace (with "private": true).

Is it possible to configure the bot to not comment on those PRs? It is distracting for our users who think they need a changeset added, when in reality we do not usually bump these packages.

Alternatively, is there any condition where the bot doesn't trigger on a new PR that we could leverage? Happy if there is some workaround that we could use.

Example PR: withastro/astro#1042

@cristobal
Copy link

I guess this is kind of related with #11.
From what i see the changeset bot works pretty well in the two following cases:

  1. A non monorepo single package
  2. A monorepo where all packages are published

But it does not work well with the case where one has a monorepo where only some of the packages under the monorepo are actually published to npm and intended to be under controll of the changesets bot.

My thought here is that some architecture changes to how the bot should behave must be done to accomplish this feature.

@timbonicus
Copy link

+1 to this feature, we have a monorepo where packages are marked private while in-development, until they are ready to be published. Enabling the changesets bot in this repo is noisy/actively misleading for authors developing those packages, but it would be super nice to have enabled for packages that are actually published.

This seems in line with changesets in general, since it does not attempt to publish private packages.

@mseibert
Copy link

+1

We have the same problem and would love this kind of scoping.

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

4 participants