| 00:02 | <ljharb> | bakkot: looks like the biblio job failed https://github.com/tc39/ecma262/runs/5400126286?check_suite_focus=true |
| 00:02 | <ljharb> | i think it's missing the checkout action |
| 00:03 | <ljharb> | one sec, i'll put up a PR |
| 00:04 | <bakkot> | beat you to it: https://github.com/tc39/ecma262/pull/2679 |
| 00:04 | <bakkot> | I wonder what sort of job doesn't need the repo checked out, such that it is not the default behavior |
| 00:04 | <ljharb> | ha, ok - my change also avoids setup-node in favor of using the same setup as the rest of the actions |
| 00:05 | <bakkot> | setup-node is the standard thing, no? |
| 00:05 | <bakkot> | like the one github itself maintains |
| 00:05 | <ljharb> | yes |
| 00:05 | <ljharb> | not very well, tho :-) |
| 00:06 | <bakkot> | I think I'd prefer to stick to the standard thing absent some reason to switch |
| 00:06 | <bakkot> | I know this particular setup works for publish jobs, since it's what ecmarkup is already doing |
| 00:07 | <ljharb> | the main reason would be consistency with everything else in ecma262 |
| 00:07 | <ljharb> | but sure |
| 00:07 | <bakkot> | We could change the others to match I guess |
| 00:07 | <bakkot> | what's the thing you like better about your version? |
| 00:07 | <ljharb> | sure. but then we might be stuck on an older node for 2 years like setup-node was |
| 00:08 | <ljharb> | the main thing i like is that it supports, via nvm, any node version we like, without any explicit maintenance |
| 00:08 | <ljharb> | setup-node requires an explicit change for it to support a new version of node |
| 00:08 | <bakkot> | ah, for our projects I think that is unlikely to end up mattering |
| 00:08 | <ljharb> | (it also abstracts away a bunch of stuff for older nodes that ofc doesn't apply here) |
| 00:13 | <ljharb> | https://www.npmjs.com/package/@tc39/ecma262-biblio |
| 00:14 | <bakkot> | wait, damn it: Version 1.0.1 |
| 00:14 | <bakkot> | ... the clone is shallow, isn't it |
| 00:14 | <bakkot> | argh |
| 00:15 | <ljharb> | oops, lol yes, it is |
| 00:15 | <ljharb> | unless you add a depth thing to the checkout action |
| 00:16 | <ljharb> | so, to use it, add --load-biblio @tc39/ecma262-biblio to my ecmarkup command, and also install the package? |
| 00:16 | <bakkot> | that is a reasonable default but not what I actually wanted |
| 00:16 | <bakkot> | indeed! |
| 00:16 | <bakkot> | you will need the latest (major) version of ecmarkup, ofc |
| 00:18 | <bakkot> | ljharb: https://github.com/tc39/ecma262/pull/2680 |
| 00:19 | <ljharb> | I’m actually about to head out; ok if i land it in a few hours? |
| 00:19 | <shu> | my experience with any and every CI commit is a series of fixups with commit messages like |
| 00:20 | <shu> | "argh", "test", "test2", "maybe this works?" |
| 00:20 | <bakkot> | ljharb: yeah no rush |
| 00:20 | <ljharb> | yeah that’s why i suggested running a dry run on every PR :-p |
| 00:20 | <bakkot> | just needs to happen before the next commit lands, so that the build doesn't break |
| 00:21 | <bakkot> | dry run wouldn't've caught this particular thing, alas |
| 00:21 | <bakkot> | but yeah would've caught the first one |
| 03:55 | <ljharb> | nah it'd still have done a dry run with the wrong version number, and also a shallow checkout, so i think we'd have seen it |
| 03:57 | <ljharb> | Related: should we tweak it so it only publishes a new biblio when the lockfile or the spec changes? |
| 04:01 | <ljharb> | and we've got a v1.0.2251 |
| 04:10 | <bakkot> |
I thought about it but decided I was too lazy, given that versions are free |
| 04:11 | <bakkot> | biblio generation is deterministic, so it would just be a matter of generating it locally, fetching the most recently published one, and diffing the two |
| 04:11 | <bakkot> | but like |
| 04:12 | <bakkot> | I didn't really feel like it was necessary enough to be worth doing |
| 05:37 | <ljharb> | any proposal repos with both a lockfile and dependabot set up are gonna have a bad time :-p but they’re probably screwed even with that optimization, so ¯\_(ツ)_/¯ |