duel 0.1.1 → 0.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: da30e26518ff9b626552115d24595276b5f6f371cc4cd9c614b126666a065898
-  data.tar.gz: d863cf940c61196483a7521ec8066385e4b2cc9071ec00c96bc6f794c266342c
+  metadata.gz: 4cc965d0ce98a08843bc8c1e1c2029045f029a9a4ae3cb05c6fa44c4a1dd7cc4
+  data.tar.gz: 54a78bbafc884061376d691fe80f6db3e034d837dcf3d2a8448d50522758f669
 SHA512:
-  metadata.gz: 777b2dc46c93019d739aed99764ac70ecdf761e1309944cdacf449b735b6a931d965fa3fc3b37141874dfeb9b8074ce120f070e4e764ecc15f9b1edbe00617d0
-  data.tar.gz: 2879233c357cfd504d0b872efd37495cdf64e115da6ed9917fe1b0fad6ad0b7f070e8c2ed9b1cdf5b4b7444a3d7dbfeaa3155fe1cac58b425890dca99ce4f19a
+  metadata.gz: 28a9a52155e5aa377428a359b2fb0c5c17b6518f9c2af07c473afb66b772c5e46825bb5f712df21590d60d65e35f2446e9412e93013cca2332bcc5bb99f94da0
+  data.tar.gz: be20c6a67c205344149983ae8e01d49570eb2406d4ff2a4dcf828ea3ab03a260faa7ce782fec119f8257b9138b15bc877b2747f4f7fb1c9c4b3ae2a8c60a4a07

data/CHANGELOG.md

@@ -7,6 +7,71 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.1.2] - 2026-11-02
+
+### Added
+
+- `c.fail_on = :pull_requests` (or `duel --fail-on pull_requests`) fails
+  a regression only in a pull request (or a merge queue), and outside
+  GitHub Actions. On GitHub Actions, a regression in a push, the
+  schedule, or a run by hand passes, with a warning, and the workflow
+  that `duel init` writes comments on a pushed commit with the report,
+  as `c.comment` says, which notifies the commit's author. The default,
+  `:every_run`, fails every run, as before, and comments on no commit.
+- `c.push_base = :last_passed` compares a push with the last commit
+  that Duel passed, which a branch marks (`duel/passed/main` for
+  `main`, and each branch the workflow guards has its own), instead of
+  the commit before the push, so slowdowns too small for any one push to
+  fail add up until they fail one. The workflow that `duel init` writes
+  moves the branch when a push passes. The default, `:before`, compares
+  a push with the commit before it, as before.
+- `c.accept_label` names a pull request label that accepts a regression:
+  with it, the regression passes, with a warning, and the report says
+  so. The workflow that `duel init` writes passes the pull request's
+  labels to `duel` (`DUEL_LABELS`), or for a push, the labels of the
+  pull request that merged it. By default, there's no such label.
+- `duel init --gitlab` writes GitLab CI jobs to include from
+  `.gitlab-ci.yml`, instead of GitHub Actions workflows. They compare a
+  merge request with the branch it targets, comment on it, and with
+  project access tokens, comment on a pushed commit and mark a push
+  passed. On GitLab CI, `duel` reads a merge request's target and labels,
+  writes its decisions to `DUEL_OUTPUT` as variables, and where only a
+  merge request fails (`c.fail_on`), exits with status 3 for a
+  regression outside one, which the job lets fail, as a warning.
+- The workflow that `duel init` writes runs for a merge queue
+  (`merge_group`), and compares its group with the queue's base, so the
+  Duel check can be required with a merge queue.
+
+### Changed
+
+- To upgrade a project that ran `duel init` before 0.1.2, delete
+  `.github/workflows/perf.yml` (or `perf-<its path>.yml`, for a project
+  in a subdirectory) and run `duel init` again, then carry over any
+  edits of your own. It writes both workflows, and skips the files that
+  exist, such as `.duel.rb`. Kept, the old workflow comments on a pull
+  request itself, and with the new one, every comment comes twice.
+- A pull request gets its comment from a second workflow that `duel init`
+  writes, `.github/workflows/perf-comment.yml`, which runs once the Perf
+  workflow has (`workflow_run`), with a token that can write, so a pull
+  request from a fork gets a comment too. It runs none of the pull
+  request's code, and trusts only what Duel could have said in the
+  report's artifact. The Perf workflow no longer has a Comment job, and
+  for a project in a subdirectory, it's named for the directory, as
+  `Perf (gems/parser)`.
+- The workflow that `duel init` writes cancels a pull request's run
+  when a newer push to the pull request starts one. Every other run,
+  such as a push's to `main`, still runs to the end.
+- A push whose commit before it isn't in the history now reports that
+  there's no commit to compare against, and passes, from `duel` itself.
+  The workflow no longer checks this in its Compare step.
+
+### Fixed
+
+- On GitHub Actions, a pull request is compared with the branch that it
+  targets (`GITHUB_BASE_REF`), not the main branch. A pull request into
+  a stable branch, or into another pull request's branch, was compared
+  with `main`.
+
 ## [0.1.1] - 2026-10-26
 
 ### Added
@@ -357,6 +422,7 @@ needs Ruby 3.4 or later (or JRuby 10, or TruffleRuby 40).
   Anything marked `@api private`, in lib/ and sig/, may change in any
   release.
 
-[Unreleased]: https://github.com/sferik/duel-ruby/compare/v0.1.1...HEAD
+[Unreleased]: https://github.com/sferik/duel-ruby/compare/v0.1.2...HEAD
+[0.1.2]: https://github.com/sferik/duel-ruby/compare/v0.1.1...v0.1.2
 [0.1.1]: https://github.com/sferik/duel-ruby/compare/v0.1.0...v0.1.1
 [0.1.0]: https://github.com/sferik/duel-ruby/releases/tag/v0.1.0

data/README.md

@@ -201,6 +201,7 @@ the limit, use `--timeout`.
 | `0` | Nothing got slower, or there was nothing to compare. |
 | `1` | Something got slower, or a benchmark failed. |
 | `2` | Duel couldn't compare. |
+| `3` | Something got slower outside a merge request on GitLab CI, where only a merge request fails ([`c.fail_on`](docs/configuration.md#fail-only-a-pull-request)). The job that `duel init --gitlab` writes lets it fail, as a warning. |
 
 ## Run Duel in CI
 
@@ -215,6 +216,10 @@ duel:
     GIT_DEPTH: 0 # the baseline comes from history
 ```
 
+`duel init --gitlab` writes GitLab CI jobs for you, which compare a
+merge request with the branch it targets and comment on it. See
+[Run Duel on GitLab CI](docs/ci.md#run-duel-on-gitlab-ci).
+
 To run Duel from Rake, define a task with `Duel::RakeTask`. Any
 arguments after the task's name are passed to `duel`:
 
@@ -225,8 +230,10 @@ Duel::RakeTask.new(:perf_since_release, "--base", "last-release")
 ```
 
 `duel init` writes a GitHub Actions workflow,
-`.github/workflows/perf.yml`. It compares each pull request with the
-main branch, each push to `main` with the commit before it, and, on a
+`.github/workflows/perf.yml`, and a second one,
+`.github/workflows/perf-comment.yml`, that comments on a pull request,
+a fork's too. It compares each pull request with the
+branch that it targets, each push to `main` with the commit before it, and, on a
 schedule, your last release, to catch slow creep. It also comments on a
 pull request with Duel's report when a benchmark fails. For the
 workflow, and for a branch that upgrades Ruby, see
@@ -304,6 +311,17 @@ but nothing to compare, or never, set
 in `.duel.rb`. For more information, see
 [Comment on a pull request](docs/ci.md#comment-on-a-pull-request).
 
+In a project where people push to `main` directly, set
+[`c.fail_on = :pull_requests`](docs/configuration.md#fail-only-a-pull-request)
+to pass a regression in a push, with a warning, and comment on the
+pushed commit with the report instead. To compare each push with the
+last commit that passed, instead of the commit before it, so that small
+slowdowns add up until they fail a push, set
+[`c.push_base = :last_passed`](docs/configuration.md#compare-a-push-with-the-last-commit-that-passed).
+To accept a regression that's on purpose, label the pull request, as
+[`c.accept_label`](docs/configuration.md#accept-a-regression-with-a-label)
+says.
+
 ### Show that a project is guarded
 
 To show that Duel guards your project, add its badge to your README,