[JENKINS-37694] Display artifacts of a running build

[jglick]

See JENKINS-37694.

Proposed changelog entries

• The build index page will now display an artifact summary and link to the artifacts list even if the build is still running.

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[jglick]

File corruption could potentially be avoided if

jenkins/core/src/main/java/hudson/FilePath.java

Lines 2838 to 2853 in 52acfa9

	File f = new File(baseDir, te.getName());
	if (!f.toPath().normalize().startsWith(baseDir.toPath())) {
	throw new IOException(
	"Tar " + name + " contains illegal file name that breaks out of the target directory: " + te.getName());
	}
	if (te.isDirectory()) {
	mkdirs(f);
	} else {
	File parent = f.getParentFile();
	if (parent != null) mkdirs(parent);
	writing(f);
	if (te.isSymbolicLink()) {
	new FilePath(f).symlinkTo(te.getLinkName(), TaskListener.NULL);
	} else {
	IOUtils.copy(t, f);

were reworked to use a temporary file + atomic move, but that could have farther-ranging effects. Anyway we already rendered the artifact list from direct navigation, exposed artifacts via REST, etc. for running builds and no one seems to have complained about this not being atomic.

[timja]

seems a bit weird to include the last line in a user facing message =/.

I would omit it

[jglick]

Well, it could potentially happen to you that the build happens to be in the middle of archiving some 3Gb binary, and you see it listed on the artifacts page and innocently go to download it and get a partial file. Rather unlikely in practice but seems appropriate to note the possibility.

[oleg-nenashev]

Would it make sense to just fix the issue and prevent corruption?

[jglick]

just […] prevent corruption

As in #5496 (comment) I think the risk involved in changing how the general tar function works, especially verifying that this works properly on Windows and NFS (how many times have we patched the likes of AtomicFileWriter?), probably outweighs the small risk of partial artifacts being listed & served in more cases (they already were in some cases). I would rather not hold up this small and low-risk fix for a very real and commonly encountered bug.

Also note that users of artifact-manager-s3 (or any other plausible JEP-202 implementation using third-party blob storage) should not have any such issue to begin with.