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

Why?

I don't want only to be notified in the comment that certain Pull Request includes changesets.
To see what's the content of it, I have to see the code changes. Hence, I don't know if they will display correctly or not. And if they're described well enough.

So, what am I proposing?

Add a configurable option, e.g., previewInPRComment, which can be disabled by default to preview the content of changesets which has been added to a certain Pull Request.

It could potentially make it simpler for us to focus on writing a meaningful changeset inside the PR dedicated to specific change.
Instead of constantly making changes to the generated Pull Request with release/versioning changes. We can get easily forgetful to remember what exactly changed there.

I have a library which lives in a monorepo, so my changeset directory lives in <repo>/library/.changeset instead of <repo>/.changeset.

changesets/action supports that, but the bot doesn't. Is there any way to add a configuration to the bot itself? Or perhaps a setting in a new root config file.

Hi,

I noticed that this bot used to be an action, but it didn't work for forks, so it was moved to a bot.

Have you considered moving it back to a github action now that you can use pull_request_target?

Moving it to an action would let users customize things. For example, I'd like to disable the bot when PRs only modify certain folders.

I believe the bot is detecting the wrong version here. Both changesets are minor, but the bot is predicting major for one pacakge. Am I missing something?

I would love if we could configure this to only run if there is a .changeset/config.json file present in the repository.

Custom commit message generators have been a documented feature for about three months now, but changeset-bot is not aware of them:

Some errors occurred when validating the changesets config:
The `commit` option is set as [
  ...
] when the only valid values are undefined or a boolean.

I was discussing changesets with a friend and we are a little worried that when making cross-package changes in our monorepo, we may forget / fail to add a changeset for all the packages that should be released. The changeset bot is pretty handy for a warning in general that there's no changeset for the PR, but we would like to get an overview actually for which packages our PR made changes for, and for which packages a changeset is made.

So we would get something like:

Changeset Bot
Hey, I see you're making changes to some packages that are not scheduled to release via a changeset:
✔️ package-a
❌ package-b
✔️ package-c
This might be intended, but I'm adding this message here to make sure :)

I wonder if this would interest you guys

Similarly to #27, right now the changeset warning message looks like:

But I think it could be simplified and more clear as:

Is there a way to change the default path where the bot creates the changeset as I currently have changeset folder in a different directory and then 2 different changeset folders in the project

I‘ve added changesets bot to a GitHub Repo with a bunch of pre-existing open Pull Requests. On new pull requests the bot does a great job of commenting. Is it possible to get the bot to comment on all those requests that where opened before the changesets bot was added?

Can the changeset bot do it?

This is a feature request (or maybe me trying to find out if this is even feasible to do; if it is, I might have a stab at making a PR): when the bot finds changesets in a PR, it will post a comment to the PR saying so. It would be great if this comment would also include the contents of the changesets. This would be a nice, frictionless way of surfacing the changes in the PR.

In my repo, if I create a mybranch branch off of my dev branch, then make a PR with mybranch but accidentally keep the base as main, then the changeset bot correctly detects changesets that are in dev, but not yet in main.

However, when I then correct my mistake and change the base of the PR to dev, the changeset bot does not try to revalidate, so keeps saying there are changesets in my PR when in fact there aren't any.

If the changeset bot could react to a PR changing its base and redetect changesets, this issue would be fixed.

Hello,

Is there a way to install this bot in Github Enterprise?

Thank you

It seems that there is no support for this so we always land here:

Right now the success message looks like:

But I think it could be cleaned up and improved to look like:

With the addition that the table could be smartly collapsed only when the number of packages is greater than 10 (or whatever the right number is), so that in the simpler cases it can just always show.

Is it possible to configure the app behavior per repo via .changeset/config.json (or some other way)? If so, it would be nice to filter branches that the bot acts on, i.e. there's no need to leave a comment on renovate/* branches.

I think Changesets normally runs Prettier when adding new changeset files. But the little link to click from the bot's comment to create a new changeset file doesn't. So if the file doesn't conform to the project's Prettier config then it will fail (eg. if needing single quotes) and render the PR invalid.

In the latest version of changeset, @Andarist added the changedFilePatterns option which let's you configure when a changeset should be needed and not.

It would be nice for the bot to validate that this config is adhered to. For example, given the following config:

{
  "...": "",
  "ignore": ["www"],
  "changedFilePatterns": ["src/**"]
}

The bot would trigger a CI step to check the changed file for the PR and validate it accordingly:

• If a PR makes changes to src/**, and there is a changeset - CI should pass.
  • Note that we need to check the ignore field here, i.e. changes to www/src/** should not require changeset.
• If a PR makes changes to src/**, and there isn't a changeset - CI should fail.
• If a PR doesn't make changes to src/**, yet there is a changeset - CI should fail.

@Andarist suggested you could do this manually using changeset status but would be nice to have this supported by the bot out of the box - perhaps there's some other nice integration with the current comment the bot leaves that could be made here too in regard to this config option / CI step 🤔

The changeset bot lists packages that aren't in a pull request's branch, but they're in the base branch. It's as if it's based on changeset status instead of changeset status --since <baseBranch>. It gives a false impression that packages in the PR have new changesets when they don't.

Previously the bot would reference the actual changed packages, but around a week ago it has stopped doing this and has started referencing @fake-scope/fake-pkg instead. I don't believe anything has changed on my end.

An example PR would be: emotion-icons/emotion-icons#142.

I've been exploring changesets recently and am in a mostly good place.

I have it working in three repos as expected.

One repo confused the bot in ways I can't understand. I keep getting:

🦋 No Changeset found

no matter what I try.

My current status:

• new branch in repo
• deleted all the files
• ran the usual:
  • yarn init
  • yarn add @changesets/cli && yarn changeset init
  • modify "commit" to true in config
  • git add .changeset/ package.json yarn.lock
  • git commit
  • git oush -u

Then I create and view the PR.

🦋 No Changeset found

This is a summary of the branch:

❯ /bin/ls -a
.                       .markdownlint.jsonc     node_modules
..                      .markdownlintignore     package.json
.changeset              .pre-commit-config.yaml terraform
.git                    .pytest_cache           yarn.lock
.infracost              .venv
❯ tree .changeset/
.changeset/
├── README.md
├── config.json
└── weak-beans-share.md

1 directory, 3 files

and

❯ cat .changeset/weak-beans-share.md
---
'botc-custom-script-json2pdf': patch
---

add changeset tool

I'm stumped, and don't know where to look for issues, not what to try to get the bot working as expected in this repo.

Any and all suggestions welcome.

Problem

The automatic github message is very helpful, but many times I've missed that the message says 'No changeset found' after a quick scan.
The problem I think is that the yellow warning symbol is the only scannable difference, and the user icon for the changeset-bot is the same as the 'Changeset detected' icon — so sometimes visually scanning, I'll see the pretty butterfly which belongs to the github bot and think there's a changeset already added (The tick as suggested in #27 would help with this).

Proposed solution

• Make the success message significantly more brief than the 'No changeset found' message
  Both the 'detected' and 'not detected' versions of the message are pretty much the same length and have the same elements. In the success message, the 'Not sure what this means?' message could be easily omitted, or added as an inline link instead. The long 'Click here if you're a maintainer ...' message could also be much shortened to 'Add another changeset' as this is very much now a less critical call to action

For my project we have a convention of listing the packages being touched in a PR in the title, so the pull request page will look something like:

• package-A: Add new feature
• package-B,package-C: Fix some bugs
• pkg-D: Do some work

This is an error prone, inconsistent, non-filterable system. It occurs to me that we could be using tags rather than coding this info in the PR title. If we're going to do that, then we could take advantage of the changeset-bot to do this automatically for us. It will be able to give us more consistent data and will also make it obvious at a glance what kinds of changes are in the PR pipeline.

The tags would probably be something like package-name - major for e.g.

This tagging solution might not be appropriate for all users of the changeset bot, so it would probably make sense for it to be an option feature which can be switched on/off.

Hi all,

Seems to me that the bot is not running in every repo I know, both new and old (already configured)

Any ideas?

Thanks :)

Related Issues:

#39: Same root cause, but different use case.
changesets/changesets#436: same issue in CLI.

Problem:

Hi, I've been really enjoying the DX of "add a changeset if you're a maintainer". But whenever a PR modifies both public and ignored/private packages, changeset/bot lists all of them in the yaml header. If we don't remove those ignored/private packages manually, this will throw

Mixed changesets that contain both ignored and not ignored packages are not allowed

Example PR: aws-amplify/amplify-ui#628. This repository has private docs and e2e packages that are ignored, but they still show up in the "add a changeset" link.

Expected Behavior

Remove ignored and/or private packages from changed packages list. This will especially help external contributors that aren't too familiar with the repo.