New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Error 412 while using recent Turbo versions #323
Comments
we've been having the same issue using Azure. Locked in at turbo v1.10 for now until we have time to fully investigate |
I've found what is causing this in my particular case. I have two different workflows. I was only seeing this issue appear in one of them. Both of them utilize my GH Action to start a cache server like this: - uses: trappar/turborepo-remote-cache-gh-action@v2
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
with:
storage-provider: s3
storage-path: turborepo-cache However, the one that was failing had the following proceeding it: - name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::${{ secrets.ACCOUNT_ID }}:role/[REDACTED]
aws-region: us-east-1 If I simply switch the order of these so that the remote cache server starts before configuring AWS credentials, then the error disappears. So this may or may not be a bug depending on which credentials should take precedence. I assumed that the Regardless of if this app is doing something wrong or not, it does seem like there's room to improve the handling of this authentication failure case. These Maybe someone who knows more about AWS authentication could help here? |
I don't think
|
Does anybody know of alternatives to ducktors / turborepo-remote-cache that don't have this issue? |
I'm seeing this as well, 1.10.16 works but newer versions do not. |
last compatible turbo version is 1.12.0, for me/us |
馃悰 Bug Report
I updated Turbo from
1.10.16
to1.12.5
today and started seeing this in CI:There is some discussion around this in this turbo issue, where people mention that this is likely due to using this remote cache server along with S3 specifically.
To Reproduce
I doubt that it will be possible for me to create reproduction instructions / repo for this issue considering that others have failed to reliably reproduce this in the thread above.
Expected behavior
To not get the http status errors.
Your Environment
trappar/turborepo-remote-cache-gh-action@v2
, which is a new version I've been working on in order to support the up-to-date version of this package.1.12.5
ubuntu-latest
The text was updated successfully, but these errors were encountered: