Uh oh!
There was an error while loading. Please reload this page.
chore: bump notify from 7.0.0 to 8.2.0 - #5374
Conversation
snth
commented
Mar 27, 2026
@dependabot rebase |
Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry! If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request |
prql-bot
commented
May 17, 2026
Skipping automated approval — this is a major version bump ( |
…ution (#605) ## Summary Step 3 of the nightly skill only looked for conflicted PRs authored by `$BOT_LOGIN`, so Dependabot/Renovate PRs left in `CONFLICTING` after the bot stopped rebasing (typically lockfile rewrites on `main` that the bump also touched) sat untouched forever. This change extends Step 3 to also query `app/dependabot` and `app/renovate`. For each upstream-bot PR, after confirming the branch carries no human commits, the nightly run triggers the bot's own rebuild path rather than rebasing manually — the bot owns the branch and force-pushes, so a manual rebase would be discarded: - `dependabot[bot]` → post `@dependabot recreate` as a comment - `renovate[bot]` → edit the PR body to tick `[x] <!-- rebase-check -->` (Renovate has no comment-based rebase command) `pre-commit-ci[bot]` is intentionally not included — it has no recreate/rebase mechanism; conflicted autoupdate PRs get superseded by the next weekly run. Inline note flags the `app/dependabot` (PR `--author` slug) vs `dependabot[bot]` (commit-author login) discrepancy so the no-human-commits check doesn't false-positive on the bot's own commits. ## Test plan - [ ] Next PRQL nightly picks up `PRQL/prql#5374` (notify), `PRQL/prql#5543` (ariadne), `PRQL/pyprql#632` and posts `@dependabot recreate` on each - [ ] Dependabot rebuilds the branches and the PRs go from `DIRTY` to `CLEAN`
prql-bot
commented
Aug 9, 2026
Revisiting this in weekly maintenance — my earlier comment's blocker is stale, and the red CI shown here isn't current signal. The MSRV objection no longer applies as stated. When I wrote that comment the repo's The Requesting a recreate below to get a fresh lockfile against current |
prql-bot
commented
Aug 9, 2026
@dependabot recreate |
Bumps [notify](https://github.com/notify-rs/notify) from 7.0.0 to 8.2.0. - [Release notes](https://github.com/notify-rs/notify/releases) - [Changelog](https://github.com/notify-rs/notify/blob/notify-8.2.0/CHANGELOG.md) - [Commits](notify-rs/notify@notify-7.0.0...notify-8.2.0) --- updated-dependencies: - dependency-name: notify dependency-version: 8.2.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
c0b125a to
a713c8aCompare
prql-bot
left a comment
There was a problem hiding this comment.
The recreate did what it needed to: fresh lockfile against current main, and the full matrix is green — including test-msrv, which was the blocker in my first comment.
Checked the major bump rather than taking green CI at face value. notify 8.0's only breaking changes are the MSRV raise to 1.77 (notify 8.2.0 declares rust-version = "1.77"; this repo is at 1.81.0) and a Windows FILE_NOTIFY_INFORMATION unaligned-access fix; 8.1/8.2 are fixes and a flume channel feature. Nothing in the surface prqlc/prqlc/src/cli/watch.rs uses changed — RecommendedWatcher::new(tx, Config::default()), Watcher::watch, and the exhaustive EventKind match all still compile without a wildcard arm, so notify-types 2.0 added no variants. That bump also drops the unmaintained instant crate from the tree, which is a small win for cargo-audit.
One caveat for the merge decision: prqlc watch has no test coverage, so green CI proves the bump compiles and breaks nothing else — not that the watcher still behaves at runtime. Given the scope (one optional CLI subcommand) that seems like acceptable risk, but it is not something CI checked.
CI note — first-pass red was a flake
test-rust (x86_64-unknown-linux-gnu, ubuntu-24.04, default,test-dbs-external) failed on the first pass with Error: Timed out waiting for: tcp:1433 — the MSSQL service container did not accept connections inside the 60s wait-on window. No test ran; unrelated to this bump. The tests workflow is green on recent main commits, so it is not a standing failure. I re-ran the failed job (job 93229101360) and it passed; check-ok-to-merge is now green.
Uh oh!
There was an error while loading. Please reload this page.
Bumps notify from 7.0.0 to 8.2.0.
Release notes
Sourced from notify's releases.
... (truncated)
Changelog
Sourced from notify's changelog.
... (truncated)
Commits
a1d7c2dPrepare release (#706)c685ea7Skip allModifyevents right after aCreateevent, unless it's a rename e...e36d54efix: INotifyWatcher may raise events with no paths (#700)394ef18feat(inotify): notify a user if themax_user_watcheshas been reached impli...04473dechore: Prepare 8.1.0 release (#697)12a026dfix: makePathsMut::commitconsuming (#695)d824023feat: introduceWatcher::paths_mutfor adding/removing paths in batch (#692)b984134Do not clone paths while walking dirs (#693)416ba82chore: Use MSRV for Clippy and rustfmt (#694)10ce3efUpdatewindows-systo v0.60 (#691)Most Recent Ignore Conditions Applied to This Pull Request