Now that we've installed Node 20 on the runner host, the setup-image job can run! Unfortunately, building the CI image seems to crash the host by eating up its entire 2GB of RAM.
I just…
I've confirmed that the checkout action uses Node 20 by looking at its action.yml. I'm still not sure how it's able to…
@glen wrote in StudioInfinity/dyna3#75 (comment):
OK, it started! And then promptly failed with
Cannot find: node in PATH. Is this referring to…
Which labels did you choose when you registered the runner? These should be listed under the "labels" key in the registration result file, which is called .runner by default. If you didn't…
I just pushed a commit with the image setup job (15375dc). If it runs as expected, I'll start working on using Cargo to run CI directly on a development machine, as discussed above. Right now, the…
I've filed an issue about adding a convenient way to do all three continuous integration checks in one command. If we added that,…
I think we don't quite have a unified harness for all tests; I think some run with cargo test and others run by invoking a shell script.
Calling cargo test should run all of our automated…
OK in light of all the above, the question is how annoying will a 4 minute wait for automated runs be? Since our s.o.p. should be to always run the tests locally before committing (in fact, I…
Finally, if we are using this locally as the way to run tests during development, we definitely want that as fast as possible, i.e. every step runs directly on my machine not through docker,…
And what's the additional time required by the isolation-breaking one, as compared to when you had the image pre-created? Is the self-hosted step quicker the second time, or does it always fully…
I have two options ready to push. Which one would you like me to try?
Install Trunk during continuous integration
On my development machine, this adds about 3.5 minutes to the CI…
[…] continuous integration, more or less by definition, has to run entirely from the repository contents
Good point; it would be nice for the repository to completely specify the build…
I've looked at the Docker output from the last workflow failure:
fjord(version:v6.3.1) received task 10 of job 1, be triggered by event: pull_request
workflow prepared
🚀 Start…
Awesome. By the way, did you cancel the continuous integration workflow for this pull request? If not, it seems to have timed out. Maybe registering the runner will cue a retry.