Closed Connoropolous closed 2 years ago
Hmm looks good, do you know what’s up with the macos failures @Connoropolous ?
ah it appears to just need more time. Exceeded the 55 minute cap
hm, also, it seems like that is because the macos nix setup took 45 minutes, while the ubuntu took 4 minutes, so that could just mean we should disable the macos one
Once the macos succeeds once it will write to cachix if we have the timer available — then it will be a bit slower than ubuntu but not 2x+ in my experience.
It’s pretty badass to have macos CI IMHO, instead of waiting for Mac based devs to complain. Also last I checked holochain core did not have any mac CI, so you may catch core bugs that they are ignoring.
Now we have an actual assertion in our test suite failing on Mac, so that's one to investigate. I use Macos too and I think I see the same thing happening. Oddly not happening on ubuntu
CI FTW 😍
I'm surprised you are having luck with npm run
(as opposed to pnpm run
), but eh- if it ain't broke...
I hadn't realized those two were npm
instead of pnpm
. I think I was just modifying code I brought from elsewhere. I'm sure pnpm
would work and then it would be more consistent 👍
I will try to investigate the failing assertion. I am also hoping that I can figure out how to get a better stack trace than just 'error thrown in tryorama middleware'. It doesn't show the line number in the hREA code.
It is a bit "divide and conquer" in that way. All you get from the JS side is "error of type XXX" with maybe some nice metadata to help you debug if it's an error I've manually caught and reinterpreted in hdk_records
. From there you often need to add debug!
output to crates and run tests individually (ie. run with npx tape
from test/
, not piped to a TAP aggregator as with the toplevel npm run test:integration
).
Speaking of, I've noticed in this new TAP runner that errors are harder to pin down in integration tests. I used to get better stacks, I swear. Could be something to do with source maps, could just be the output vs that of faucet
?
Anyway it seems like it's just an OSX thing so I'm interested to see what the incompatibility is.
"Speaking of, I've noticed in this new TAP runner that errors are harder to pin down in integration tests. I used to get better stacks, I swear."
If you can re-install tap-spec
and do a side by side comparison I'd love to see. I am intent on getting better stack traces
Any help on how I can set this on: [push, pull_request]
to only run 1 set of checks for PRs (I think, just pull_request
); but also run for updates to the main branch? That way we can avoid a lot of unnecessary test resources & spam for pushes to in-progress branches.
Ooorrrrr is "push" needed to re-run tests on pushing an update to an existing PR? Cos we do need that.
Ooorrrrr is "push" needed to re-run tests on pushing an update to an existing PR? Cos we do need that.
Yeah that's it
replaces #195 because was having issues with the git history there.