mcptask-rails-runner 0.3.19-aarch64-linux → 0.3.20-aarch64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c41fe0c5aa1f09717740d4fa9c16248f40f93589544671a3c7a24983372be936
-  data.tar.gz: 1a1f66c63d8fd588faf4b0dbb4635315fb239580779a068a440025b956a2461b
+  metadata.gz: f30682bd3e11e468cb0a59acced8ab9fd43ec373777bf656f855fea8dae43434
+  data.tar.gz: feab7c4baa66b2f87ad031fd735d9225801b85d8df9f9f40362ca9afc791fe50
 SHA512:
-  metadata.gz: a05eff5b3e5dfc703a7ccfc7b8631f728afa75c8445b6d7a15f52b288a7523c42332aa531f5bad2e5caecdf8e17a87244b36df0534e4d95f615d9a8f64a9cbf1
-  data.tar.gz: a4b40dd33eaba23092c78bfbd705bc9a257ecf17df6c8d652ce68f655ba0f893bfcfbdcaba227b4f31d069aa86b36daf642b763ed5ec36db2e7174dfc5b9cf98
+  metadata.gz: bcfb7679d58a3c32aee39cd1801933bbbe1a7f814c143531b8784d394ba8f2a7c92910de826f3cc52bca3dc928d992504d2997db76464349ff8f9df2fb28a93a
+  data.tar.gz: dca2f3316173aa1d9db438e8f737f716d48a72f59cf885bc2904517d4927c9b9aec55189f29b4b47b6cf6c670ff793deefd14c0b0a6bef912e0deb72e70cd0ed

data/CHANGELOG.md

@@ -7,6 +7,41 @@ release notes for the same tag.
 
 ## Unreleased
 
+## 0.3.20
+
+No wrapper changes. Full notes in
+[mcptask-releases v0.3.20](https://github.com/jchsoft/mcptask-releases/releases/tag/v0.3.20).
+
+**Upgrading:** run `mcptask_runner update --self` on each host, and do it for
+this one rather than at leisure — the fix below can only reach a runner that is
+running the new binary, and the situation it fixes keeps happening until then. A
+daily process picks the new copy up at its night swap, but only once that copy
+is on disk. The project bump alone still changes nothing about what the 08:00
+job runs.
+
+Binary changes carried by this version:
+
+- A piece assigned to somebody else while this runner is working it now stops
+  the child, instead of being worked to the end by a runner it no longer belongs
+  to. The dashboard socket has always carried both halves of an assignment —
+  "given to you" cut an idle wait short, and "given to somebody else" reached
+  nothing — so a task moved between two agents was picked up by its new owner
+  while its old one carried on: two agents on one piece, the same branch name
+  pushed twice, two sets of efforts logged. The runner now abandons the piece,
+  says so, and goes back to the queue for one that is still its own. It is not a
+  reason to stop the day, and the piece is deliberately not set aside: the queue
+  has already stopped offering it, and it stays workable if it is handed back.
+- The run log is coloured as it is read, and the file itself stays plain. The
+  two lines that matter in a wall of uniform text — the ones `Warn` and `Error`
+  already mark with a glyph — are painted red and yellow, a child's stderr is
+  yellow, and the `[Component]` tags, cost lines and phase separators are dimmed
+  so the shape of a run is visible in a scroll. Only what the runner itself
+  marked is coloured; guessing a severity from the wording would be wrong on the
+  day it mattered. Nothing is written to the file, which is what bug reports
+  attach and what people grep. `runner-log --paint` is the same filter over
+  stdin, so `tail -f any.log | runner-log --paint` works for a log read some
+  other way.
+
 ## 0.3.19
 
 **Upgrading:** `bundle update mcptask-rails-runner` in each project for the

data/lib/mcptask_rails_runner/version.rb

@@ -10,5 +10,5 @@ module McptaskRailsRunner
   # Binary::INSTALL_DIR. So the pin is per project and per foreground rake
   # invocation; the installed copy is per machine, and the newest binary any of
   # those projects offers is the one that stays.
-  VERSION = "0.3.19"
+  VERSION = "0.3.20"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: mcptask-rails-runner
 version: !ruby/object:Gem::Version
-  version: 0.3.19
+  version: 0.3.20
 platform: aarch64-linux
 authors:
 - Josef Chmel