gh run view --log mismatches if one job name is the suffix of another #8883

Describe the bug

Closely related to #7641.

Because attachRunLog (for gh run view --log) processes the zip file entries in zip file order, stopping at the first match, it is vulnerable to finding the wrong match, in the case where one job name is a suffix of another.

Minimal example: two jobs, "X" and "2X", both with a single step, "S":

• X/1_S.txt
• DX/1_S.txt

If the zip file entries are in that order, then all is well: searching for "X/1_" finds X, and "DX/1_" finds DX.

But if the entries happen to be the other way round:

• DX/1_S.txt
• X/1_S.txt

then search for "X/1_" find DX (as does searching for "DX/1_", still). So both X and DX show DX's log.

Reproduced against 672af276cf8735202d70e9e0d2aa08949c9c6c96.

Steps to reproduce the behavior

1. Set up a workflow which has jobs and steps as described above. To increase the chances of it going wrong, have lots of "X" jobs (AX, BX, CX, DX, ...) for "X" incorrectly to match against. You'll probably want each job-step to echo its own job + step name, so we can tell what's what.
2. Let the workflow run, then view with gh run view JOBID --log
3. Observe that the output for job X probably came from a job other than job X.

Expected vs actual behavior

I know the whole "match zip file entries to jobs + steps" is annoyingly fuzzy, but of course we would hope that it correctly matches them up. In any case, the order of the entries within the zip file probably should not matter (but it currently does).

Logs

More detailed, real example follows.

Example via which this bug came to light: here we have two jobs, rake ci_and_notify and eu rake ci_and_notify. They run the same steps, with the primary difference in the DATADOG_ACCOUNT env var, which appears in the log: us for the former, eu for the latter.

gh run view 8464816594 --log | grep ACCOUNT then shows (with a little reformatting):

rake ci_and_notify    Run zendesk/checkout@v4                    2024-03-28T08:59:59.6825141Z   DATADOG_ACCOUNT: us
rake ci_and_notify    Run zendesk/setup-ruby@v1                  2024-03-28T09:00:05.6852423Z   DATADOG_ACCOUNT: eu
rake ci_and_notify    Datadog cache: restore                     2024-03-28T09:00:12.0239009Z   DATADOG_ACCOUNT: eu
rake ci_and_notify    Run bundle exec rake ci_and_notify --trace 2024-03-28T09:00:14.5047794Z   DATADOG_ACCOUNT: us
rake ci_and_notify    Datadog cache: clear                       2024-03-28T09:00:42.4231088Z   DATADOG_ACCOUNT: us
rake ci_and_notify    Datadog cache: store                       2024-03-28T09:00:27.6408253Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Run zendesk/checkout@v4                    2024-03-28T08:59:58.4905087Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Run zendesk/setup-ruby@v1                  2024-03-28T09:00:05.6852423Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Datadog cache: restore                     2024-03-28T09:00:12.0239009Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Run bundle exec rake ci_and_notify --trace 2024-03-28T09:00:13.4179157Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Datadog cache: clear                       2024-03-28T09:00:24.5326128Z   DATADOG_ACCOUNT: eu
eu rake ci_and_notify Datadog cache: store                       2024-03-28T09:00:27.6408253Z   DATADOG_ACCOUNT: eu

The checkout steps, it has matched up correctly: rake ci_and_notify has DATADOG_ACCOUNT: us, and eu rake ci_and_notify has DATADOG_ACCOUNT: eu. So far so good.

But the setup-ruby steps, it has matched them both to DATADOG_ACCOUNT: eu.

Looking at the zip file, we can see why.

In the happy case, rake ci_and_notify comes before eu rake ci_and_notify. So the first match for rake ci_and_notify/3_.*\.txt is rake ci_and_notify/3_Run [email protected], and the first match for eu rake ci_and_notify/3_.*\.txt is eu rake ci_and_notify/3_Run [email protected].

unzip -l ~/8464816594.zip | grep ci_and_notify.*_Run\ zendeskcheckout
     7429  03-28-2024 09:01   rake ci_and_notify/3_Run [email protected]
     7365  03-28-2024 09:01   eu rake ci_and_notify/3_Run [email protected]

However, for setup-ruby, we weren't so lucky. Here, the entries in the zip file are in the "opposite" order, namely EU first:

unzip -l ~/8464816594.zip | grep ci_and_notify.*setup-ruby
     6942  03-28-2024 09:01   eu rake ci_and_notify/4_Run [email protected]
     6942  03-28-2024 09:01   rake ci_and_notify/4_Run [email protected]

which means that while the first match for eu rake ci_and_notify/4_.*\.txt is indeed eu rake ci_and_notify/4_Run [email protected], the first match for rake ci_and_notify/4_.*\.txt is also eu rake ci_and_notify/4_Run [email protected], when it should be rake ci_and_notify/4_Run [email protected].