00:04
oh dang they're removing teams discussions on github
Okay so I've done some testing with them, and I think I get how they work now
and they're actually pretty cool
and we'll be using it because it just makes life easier
"how does it make life easier?", you ask
so in the past, when there's been multiple PRs open at once, you've had to click "update branch" whenever something gets merged before everything else
and you had to do that each and every time you merged something
so if you had 4 PRs open, you would merge the first, click "update branch" on at least one of the PRs, merge a second, click "update branch" on at least one of the remaining PRs and so on
The merge queue automates that
and merges things in a nice order
there's a few settings that can be configured for how many things are merged at a time and how long until batches are merged, but for now I set it to the default settings
If a PR has failed checks while in the queue, it'll be removed from the merge queue, meaning it won't be attempted to be merge
which is basically what would happen manually
The perks of having an organisation :p
For now, I've enabled merge queues on main
and version-3
and on the sandbox main branch
if it works the way I think it works, it should basically go unnoticed
this would have been hella useful over the last 2 years
@user there's no cookie, but I tested an infinite loop of printing 1
s and it worked well
huh looks like I broke it by placing calls to worker.terminate
in cancelWorker
turns out that wasn't the case
I think what was happening was that the scala was sending so many messages so fast that even after terminating the worker, messages were still being processed by main.js
so now, if the play button isn't spinning, messages are ignored
the messages are now going into subsequent executions
gonna have to implement a sort of sessions thing