Support Forums

Headers not read for alias deploy from netlify CLI

I’m trying to add custom headers for a CSP to my site: elastic-babbage-dd5d05.netlify.app
I’ve also been trying deploying via the cli for the first time. I added some custom headers in both _headers and netlify.toml as I wasn’t seeing them in the response. On digging deeper, the headers are being read but only in the unique deploy url, not the aliased url.

For example, doing an alias deploy via:

 netlify deploy --alias dev -m "Test cli nodir"

Gave the following output:

Logs:              https://app.netlify.com/sites/elastic-babbage-dd5d05/deploys/60df696c37f112457c18ff85
Website Draft URL: https://dev--elastic-babbage-dd5d05.netlify.app

The issue is that the aliased url doesn’t include the headers while the deploy url does: see
https://60df696c37f112457c18ff85–elastic-babbage-dd5d05.netlify.app/ vs https://dev–elastic-babbage-dd5d05.netlify.app/

Further deploying to production with

netlify deploy -m "Test production deploy" --prod

Does apply the headers correctly. Any advice on why this may not be working?

Update to links after updating to netlify cli 4.0.5 and trying again with the latest deploy:

[Logs](Netlify App
Headers not set on aliased url
Headers successfully set on deploy url

Hi, @TomHall2020. Part of the issue here is a false assumption that you can reuse the same string for --alias deploys. You cannot. I have a post here which explains in more detail:

When you used --alias dev you locked dev to that exact deploy. That was deploy id 60ddf41693dc470008c3dd3a which was created on 2021-07-01 at 09:57:58 (UTC-07:00).

Your continued use of --alias dev will not cause the alias to update. You locked that to deploy id 60ddf41693dc470008c3dd3a on July 1st and it can never be changed again.

The other two deploys you linked to (60df696c37f112457c18ff85 and 60e1cb1ad44d371e8af57ad5) are not connected to dev--elastic-babbage-dd5d05.netlify.app in any way. Your changes in new deploys will never be reflected on the dev--elastic-babbage-dd5d05 subdomain because it is forever locked to 60ddf41693dc470008c3dd3a.

In other words, you cannot use the --alias option to simulate branch deploys. The are different deploy types (alias and branch deploys) and they do not work in the same way.

We do have an open feature request for the --alias deploys to create “real” branch deploys. If that feature becomes available, we will post an update here to let you know.

If there are other questions or concerns, please reply here anytime.

1 Like

Hi Luke, thanks for explaining that, all makes sense now. I think the documentation could be edited to make that behaviour more explicit, or even raise an error in the cli when attempting to deploy to the same alias a second time, as the feedback gives the impression that the deploy has been successful to that url.

I was hoping to use that as a subsitute for branch deploys, so if that does ever get implemented I would be interested. But it’s not a big deal now that I know. Thanks for the help!

1 Like

Thanks for following up with that suggestion, @TomHall2020! I have shared your feedback with our Documentation Team.

1 Like