[Chapel GA Tests] 2026-11-04

Notifications Nightly Testing
1

The following GitHub Actions jobs failed:

Ran 885 total jobs at commit f88062e47d37229164441886964d79b4bbad8aa7 "Improve CHPL_COMM=gasnet debugger exit (#29645)".

GitHub Actions run info:
2

Looking for some GA triage education here:

This seems as though it could just be a timeout for a memory intensive
test. Is there a best practice for stepping back in time within the GA
nightly framework to see how long it took to run on previous nights?

I started down the path of going back to the previous run, finding the
gasnet.darwin aggregation jobs, but then am not sure how to zero in on the
log segment that would cover the same test efficiently. Or is there a way
to just jump to the raw logs without going through the full GA interface?

Thanks,
-Brad

3

You can download the full start_test log by opening the "Aggregate ..." run of the job you are interested in, going to the "upload aggregate results", and downloading the archive.

The easiest way to find previous runs is to click on the job link from the discourse email, the GA actions view is pretty poor and hard to navigate

-Jade

4

Thanks for that info, Jade — it's very helpful.

Looks like this test has been running at nearly 30 minutes on Macs in
oversubscribed mode with small numbers of cores, so I dialed down its
number of time steps by 10x in
Dial down CoMD's nSteps for correctness testing by 10x by bradcray · Pull Request #29651 · chapel-lang/chapel · GitHub to make it a bit more
reasonable and further from the GASNet timeout for small core count
systems.

-Brad

5

Belated question on this: Would there be an easy-ish way to make the
aggregated .log file visible directly within GitHub without having to
download the .zip file containing it and a bunch of other stuff? (both
for ease of browsing and to avoid downloading, and in my case probably
never deleting, more data than I need).

Alternatively, is there a way to make the .log file downloadable without
also getting the rest of the .zip? (maybe having the option between the
two would be ideal?)

Thanks,
-Brad

6

Belated question on this: Would there be an easy-ish way to make the
aggregated .log file visible directly within GitHub without having to
download the .zip file containing it and a bunch of other stuff? (both
for ease of browsing and to avoid downloading, and in my case probably
never deleting, more data than I need).

Not really. start_test logs are massive and would overwhelm GA, the browser becomes quite unresponsive if you dump large amounts of text

Alternatively, is there a way to make the .log file downloadable without
also getting the rest of the .zip? (maybe having the option between the
two would be ideal?)

Not easily. Its a single download with all the information, multiple files mean a directory/zip is needed. Otherwise it would be multiple uploads, which is multiple chances for network throttling and we don't have unlimited upload space in GA.

Not quite what you are asking for here, but I've already started making these logs easier to find in Expand paratest emailer results by jabraham17 · Pull Request #29654 · chapel-lang/chapel · GitHub. This gets a nice balance of easy to find with practicality

-Jade

7

Thanks for considering the question.

In asking, what I was hoping for was an easier way to browse log files,
say multiple log files across multiple days, directly within the browser
without downloading and unpacking multiple zip files.

For example, in Jenkins, it wasn't uncommon for me to open 3-4 days of log
files in separate tabs to compare and contrast them. I was hoping to do
this in the new world without downloading and unpacking 3-4 zip files only
to pick the one file I cared about out of them — in part to streamline
operations, in part because I tend to be horrible at reclaiming disk
space, so imagine the zip files piling up until I go GC as my disk fills
up.

-Brad

8

I very much agree, I find having to download logs and open them in a text editor very annoying. But the GA view becomes incredibly unwieldy and laggy very quickly, especially with large outputs (like build logs, start_test logs, etc). I don't have a good solution to that yet

-Jade