Show size of uploaded artifacts and caches in the build log

What does this MR do?

Causes gitlab-ci-multi-runner to output the size of the cache and artifact ZIP files that it uploads.

Are there points in the code the reviewer needs to double check?

• Are we happy with the output format? Adding a separate line for the file size didn't look very good to my eyes.
• Should I be smarter with the units? Intelligently display closest KiB / MiB / GiB ?
• Merging the HTTP client code in commands/helpers/cache_archiver.go into network/gitlab.go would permit a common approach
• A new MIT-licensed dependency is introduced. It would be trivial to embed, rather than vendor, it.
• There are no tests for build log contents that I could find, so I didn't add any. We should definitely consider adding comprehensive tests for this at some point.

Why was this MR needed?

Sensible suggestion from user

What are the relevant issue numbers?

Closes #1320

Screenshots (if relevant)

Creating cache build/master...
./cache: found 1 matching files                    
Uploading cache.zip size=4278 bytes                
# [...]
Uploading artifacts...
./artifact: found 1 matching files                 
Uploading artifacts to coordinator... ok            id=616 responseStatus=201 Created size=4529 bytes token=Sasexv-d
Build succeeded

Have you thought about using: https://github.com/cheggaaa/pb? It would present nicely how fast we are uploading data.

Looks reasonable, and although it's not what the issue asked for, it certainly provides it! I'll look at reworking this MR to use it.

Yes, but it should be much better, because we will see a progress in case of long artifacts uploading, but also a total uploaded :)

Reassigned to @nick.thomas

mentioned in merge request !259 (closed)

Status changed to closed

!259 (closed) is preferred

In last month I had a call with customer who is having strange problems with artifacts upload size. Artifacts (which should be 30MB large) can't be uploaded due to an error 413 Request Entity Too Large. The problem is that limit in all known places is set to 100MB. Having a confirmation that runner is really sending 30MB (not, for example, 130MB) would remove one of potential causes from the list.

Since - as posted here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/259#note_16136483 - !259 (closed) is waiting for terminal support in build log, could we finish and merge this one and go back to !259 (closed) when terminal support will be ready? What do you think @ayufan @nick.thomas?

xterm.js is now vendored into gitlab-ce, so I think it makes more sense to continue to concentrate on improving the build log then merging !259 (closed) . My opinion was different four months ago, but that was four months ago :D

mentioned in issue #2316 (closed)

reopened

8 months later :D - I'll fix up the merge conflicts in this and we can see about getting it merged.