logformatter: link to logs using Cirrus API

[edsantiago]

One day we may use AWS for part of CI. Do you want to maintain
two separate code paths in this script for linking to artifacts
in multiple cloud providers? Can you say no? I knew you could.

Cirrus already knows the location of the artifacts and provides
a transparent mechanism for accessing them. Use it.

This PR exposed a nasty bug in our environment-variable handling:
envariables passed through to the containerized environment were
being double-space-escaped, so "FOO=a b" ended up as "FOO=a\ b"
(with a backslash), with one consequence being invalid URLs.
The solution is simple: run 'podman -e FOO', not '-e FOO=value'.

Finally, reinstate the environment-variable dump (in comments).
I had removed this in a moment of panic over leaking secrets,
but no, that doesn't happen.

See #14569 for discussion.

Signed-off-by: Ed Santiago [email protected]

None

[edsantiago]

Yay, seems to work: see link here: https://cirrus-ci.com/task/4690118979092480?logs=main#L53

[edsantiago]

@cevich this is failing in two cases: the two container tests. E.g. int-podman-f36-root-container. Reason seems to be spurious backslashes before the spaces: int\ podman\ fedora-36\ etc. Root cause is this escape:

podman/contrib/cirrus/lib.sh

Lines 129 to 130 in 3109534

	# Properly escape values to prevent injection
	printf -- "$envname=%q\n" "$envval"

Sure, it's easy for me to fix in logformatter, but I think this might actually be showing us that there's a problem with the variable-escaping mechanism: the variables seen in container environment are subtly different from those in other environments.

[edsantiago]

Followup: this is ready for review. I've confirmed that all the links are correct, via:

$ cirrus-pr-timing --download-logs 14608
Downloading into cirrus-pr-timing.6633932056690688:
...
$ grep -ah '  https://api.cirrus-ci.com/v1/' cirrus-pr-timing.6633932056690688/* | xargs -l1 browser-open

Every one of the links worked. (Yes, I also tested by manually clicking a handful of CI log links, but I have only so much tolerance for tedium)

[cevich]

I think this might actually be showing us that there's a problem with the variable-escaping mechanism

Ack. I'm not surprised about this. Your fix looks good, and overall this LGTM. Thanks for taking this on.

[edsantiago]

@cevich I've folded in my SECRET_ENV_RE filter and re-pushed, in case that was the blocker for merging this. You can confirm by view-source on this log. TOKEN does not appear in the list, but SECRET does because SECRET is not actually part of SECRET_ENV_RE.

[cevich]

Oh sorry and thanks for mentioning me. I completely forgot about this. I can't really read perl so I'll just trust that you've got it right.

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, edsantiago

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [edsantiago]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment