I upgraded my deploy from v25 to v42.2.0
The deployment to a "preview" environment fails to set the aliases with this error:
Deployment created: https://intelligent-foo-hznjgqtzn-mycompany-inc.vercel.app/
Building deployment...
Deployment is ready!
Alias assigned: intelligent-foo-myvercelname-9597-mycompany-inc.vercel.app
set preview-url output
set preview-url output as first alias
set preview-name output
alias domains to this deployment
retrying: attempt 2 / 3 in 3000ms
retrying: attempt 3 / 3 in 6000ms
Warning: Failed to configure alias domains: Alias assignment failed for domain preview-api.carfeine.net with status 404: {"error":{"code":"not_found","message":"Deployment intelligent-foo-hznjgqtzn-mycompany-inc.vercel.app not found"}}. The deployment succeeded but alias configuration failed.
Forcing the deploy back to CLI mode allows it to successfully assign the alias.
I think the deploy should be failed on such an error. This is a silent failure from the workflow, but it is a fatal error from my view point.
The configuration that fails to assign alias:
- name: Build and Deploy
id: build-and-deploy
uses: amondnet/vercel-action@v42.2.0
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
github-token: ${{ github.token }}
vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
vercel-project-name: intelligent-foo
alias-domains: preview-api.example.com
Forcing it to use the CLI lets the assignment succeed. Only difference is the tercel-args line and the scope.
- name: Build and Deploy
id: build-and-deploy
uses: amondnet/vercel-action@v42.2.0
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
github-token: ${{ github.token }}
vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
vercel-project-name: intelligent-foo
vercel-args: '--logs' # some harmless argument to force CLI mode
scope: mycompany-inc
alias-domains: preview-api.example.com
I upgraded my deploy from v25 to v42.2.0
The deployment to a "preview" environment fails to set the aliases with this error:
Forcing the deploy back to CLI mode allows it to successfully assign the alias.
I think the deploy should be failed on such an error. This is a silent failure from the workflow, but it is a fatal error from my view point.
The configuration that fails to assign alias:
Forcing it to use the CLI lets the assignment succeed. Only difference is the
tercel-argsline and the scope.