| 00:11 | <ljharb> | i had to revert 3006; the biblio task failed on it because it was trying to publish a sha that had already been published previously. that should probably be a silent success condition? |
| 00:17 | <bakkot> | uhhh the task uses the commit number, not the sha |
| 00:17 | <bakkot> | and the only way for the commit number to be reused is if you force-push to main, I think? reverts count as commits for the purposes of rev-list --count |
| 00:18 | <bakkot> | if you didn't force-push, I don't know what's going on there |
| 00:33 | <ljharb> | ah ok then that's what did it, i did force push, to remove my first attempt to fix it |
| 00:34 | <ljharb> | won't be doing that again :-) |
| 02:19 | <jmdyck> | pulling in the new merges, finding some bugs. |
| 03:57 | <jmdyck> | actually only one bug. |
| 04:12 | <jmdyck> | and one new inconsistency |
| 04:31 | <jmdyck> | https://github.com/tc39/ecma262/pull/3017 |
| 05:41 | <ljharb> | jmdyck: if there's any chance of making a github action to detect these things on PRs - even if it remained optional - i think it'd be very helpful |
| 14:12 | <jmdyck> | If it's optional, is there anything to prod the PR-owner to check the results? |
| 14:20 | <jmdyck> | Is there a way to set things up so that the results go to me, and then I can decide if a reported error is due to a problem in my code or a problem in the PR? |
| 16:11 | <ljharb> | they’ll still see the failures - and certainly part of the action could be to notify you |
| 18:47 | <jmdyck> | So they'd still get a red-X failure, but instead of "Required" in an oval, it'd say "Optional"? |
| 20:46 | <ljharb> | it's just say nothing, since only things with "required" are required, but yep |