ci: avoid pounding on the poor ci-artifacts container #2622
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 12, 2020
|
Companion GitGitGadget PR: gitgitgadget#632 |
derrickstolee
added a commit
to microsoft/git
that referenced
this pull request
May 13, 2020
…container I did not think through how I designed the Windows job initializing the minimal subset of Git for Windows' SDK: it currently accesses Azure Blobs and uses way too much bandwidth, blowing right through my quota. With this PR, we use the (slower) method of downloading the git-sdk-64-minimal Build Artifact of our Azure Pipeline again, which should fix that problem. This is a companion PR to git-for-windows#2622
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
avoid-ci-artifacts-for-now
branch
from
bec0334 to
3298900
Compare
git-for-windows-ci
pushed a commit
that referenced
this pull request
May 15, 2020
ci: avoid pounding on the poor ci-artifacts container
git-for-windows-ci
pushed a commit
that referenced
this pull request
May 15, 2020
ci: avoid pounding on the poor ci-artifacts container
git-for-windows-ci
pushed a commit
that referenced
this pull request
May 15, 2020
ci: avoid pounding on the poor ci-artifacts container
dscho
added a commit
to dscho/git
that referenced
this pull request
May 15, 2020
…-for-now ci: avoid pounding on the poor ci-artifacts container
git-for-windows-ci
pushed a commit
that referenced
this pull request
May 29, 2020
ci: avoid pounding on the poor ci-artifacts container
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I did not think through how I designed the Windows job initializing the minimal subset of Git for Windows' SDK: it currently accesses Azure Blobs and uses way too much bandwidth, blowing right through my quota.
With this PR, we use the (slower) method of downloading the
git-sdk-64-minimalBuild Artifact of our Azure Pipeline again, which should fix that problem.