summaryrefslogtreecommitdiff
path: root/t/lib-pack.sh
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2020-05-15 07:55:18 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-05-15 08:02:30 -0700
commit857341c1b7533cc0a813b1eb851ef2eedfacc90e (patch)
tree655f10c6a6b446a0aaa798fde51c9461fd856079 /t/lib-pack.sh
parentci: let GitHub Actions upload failed tests' directories (diff)
downloadtgif-857341c1b7533cc0a813b1eb851ef2eedfacc90e.tar.xz
ci: avoid pounding on the poor ci-artifacts container
When this developer tested how the git-sdk-64-minimal artifact could be served to all the GitHub workflow runs that need it, Azure Blobs looked like a pretty good choice: it is reliable, fast and we already use it in Git for Windows to serve components like OpenSSL, cURL, etc It came as an unpleasant surprise just _how many_ times this artifact was downloaded. It exploded the bandwidth to a point where the free tier would no longer be enough, threatening to block other, essential Git for Windows services. Let's switch back to using the Build Artifacts of our trusty Azure Pipeline for the time being. To avoid unnecessary hammering of the Azure Pipeline artifacts, we use the GitHub Action `actions/upload-artifact` in the `windows-build` job and the GitHub Action `actions/download-artifact` in the `windows-test` and `vs-test` jobs (the latter now depends on `windows-build` for that reason, too). Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/lib-pack.sh')
0 files changed, 0 insertions, 0 deletions