the family root's bootstrap.py: with SHAPE_LEGS_TOKEN or SHAPE_LEGS_APP_TOKEN set, a member's commit no branch of its remote holds (B4) still ends family bootstrap ok, with the advice to set the token that is already set #996

What happens

#954 (#892) fails the run by name where git's update died (exit 128) at a member's commit that a fetch reaching its remote did not bring (B4). It tells that apart from a missing credential by the exit code of the git fetch git ran in that member, which it reads from git's own trace2 event stream (fetched_in).

A run with SHAPE_LEGS_TOKEN or SHAPE_LEGS_APP_TOKEN set is never traced. trace2 writes each command's arguments, and the credential's -c url.https://x-access-token:<token>@github.com/.insteadOf=... is one of them. Git 2.43 also writes the rewritten url it gives a remote helper. Both are written unredacted on 2.43; 2.47.1 redacts the url but not the argument (lane 5's probe on #954). Tracing would put the token on disk.

So with either variable set, which is the usual setup for private members:

• B4 reads as before the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954: FETCH INCOMPLETE (git exit 128), the credential advice, and family bootstrap ok, exit 0;
• the advice says to set SHAPE_LEGS_TOKEN, which is already set.

#954 accepts this as a known limit (lane 5's SHOULD 4 on #954), and tests/test_family_bootstrap_stops_named.py::test_with_a_credential_in_use_b4_is_read_as_before pins it. B5, which needs no trace, is named with a token set too.

Direction (no trace2)

Make the two fetches git's update makes in that member again, in bootstrap's own process, and read their exit codes directly instead of from a trace.

• Only after git's update exits 128 with a token in use, and only for a gitlink the walk (stopped_below) reaches whose recorded commit its store lacks (commit_held).
• Run git fetch origin in that checkout with the same -c rewrite in argv as the update, and with every GIT_TRACE* variable removed from its environment, so nothing is written to disk. Then, where the commit is still absent, run git fetch origin <commit>, as git's update does.
• B4 is where the first exits 0 and the commit is still absent after the second. A first fetch that fails is the credential's skip, as now.
• The token travels as it does today, in argv only. No file is written.
• Cost: up to two fetches per such member, only on an exit 128 with a token in use.

Rejected: passing the rewrite through GIT_CONFIG_COUNT instead of argv and tracing anyway. The remote helper's url still carries the token on 2.43, and it changes how the credential travels.

Separately, where a token is set and the run is the credential's skip, the advice could name the token in use ("the token in SHAPE_LEGS_TOKEN did not reach ...") instead of saying to set it.

Verify

• B4 at IRSS with SHAPE_LEGS_TOKEN set: exit 1, UPDATE STOPPED ... git stopped at members/IRSS ..., no advice, and the token printed nowhere and written to no file under TMPDIR.
• The credential control with a token set, a remote the token's transport cannot reach and the pin moved on: the advice and ok, as now.
• test_with_a_credential_in_use_b4_is_read_as_before is turned into a row that expects the B4 line.

Found by lane 5's review of #954 (SHOULD 4, issuecomment-6253384652). Follows #892 (#954).

Parent: #459.

Milestone: v1.2.0.

Not claimed.

Lane: openreposhape-4 (openRepoShape-4)