You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The archives are a tar file, which supports streaming (de)compression. Thus, it should be possible to interleave the download and unpacking (as well as packing and upload) resulting in less overall latency.
In the bash version this would've been as simple as piping the sftp output to tar -x and vice-versa for uploads; in Go this might be slightly more tricky but in general possible and an easy win for faster builds.
The text was updated successfully, but these errors were encountered:
Hi @bertptrs. Thanks for reaching out, and sorry for the late reply.
We are looking into possible solutions for parallel downloading and unpacking. We cant just execute Unix commands such as stfp and tar because cache cli needs to work on windows machines as well, but we are exploring viable alternatives within the go language. As soon as this is implemented I will ping you.
@bertptrs before parallelizing the download/decompression, we have to remove the need for shelling out to host CLIs. This has been initially implemented in #379.
By default, the cache CLI will still shell out (we will slowly roll out this change to every organization). But you can use the SEMAPHORE_CACHE_ARCHIVE_METHOD environment variable to use the new archiving methods if it hasn't been automatically set for your organization yet.
Once that has been enabled for every organization without issues, we'll look into parallelizing the compression/decompression with the upload/download.
Cache operations can take up a long time. For our builds, the do in fact take up the majority of the time. Right now that works roughly as follows:
For example, this is the code that actually does the restore:
toolbox/cache-cli/cmd/restore.go
Lines 99 to 124 in e7de131
The archives are a tar file, which supports streaming (de)compression. Thus, it should be possible to interleave the download and unpacking (as well as packing and upload) resulting in less overall latency.
In the bash version this would've been as simple as piping the
sftp
output totar -x
and vice-versa for uploads; in Go this might be slightly more tricky but in general possible and an easy win for faster builds.The text was updated successfully, but these errors were encountered: