I’ve been experimenting with some Github actions and the Netlify CLI.
I noticed that when I added --alias to my deploy command, it released my dev site to production!
Here’s the command and logs (minus the site name & log url):
netlify deploy --dir=public --message 'use `--alias`' --alias dev
shell: /usr/bin/bash -e {0}
env:
NETLIFY_AUTH_TOKEN: ***
NETLIFY_SITE_ID:
Deploy path: /home/runner/work/mysitename/mysitename/public
Deploying to draft URL...
- Hashing files...
✔ Finished hashing 770 files
- CDN diffing files...
✔ CDN requesting 0 files and 0 functions
- Uploading 0 files
✔ Finished uploading 0 assets
- Waiting for deploy to go live...
✔ Deploy is live!
Logs: app.netlify.com/sites/my-sitename-12345/deploys/0000000000000
Website Draft URL: dev--my-sitename-12345.netlify.app
If everything looks good on your draft URL, deploy it to your main site URL with the --prod flag.
netlify deploy --prod
But then in Netlify the deploy is published.
When I remove the --alias flag, the logs are similar except there is no custom preview URL but Netlify doesn’t publish:
The only difference in the commit is the removal of --alias.
Hiya @stakinganalytics and sorry to hear about the trouble! I can’t tell without more details whether this is intended (by our system design; it’s obviously not intended by you :)) based on your site configuration. This would be intended, in case your production branch is called dev, for instance!
Could you tell me your site’s API ID? In the future, you’ll get much faster answers if you don’t obfuscate your site name and deploy ID since I wouldn’t have had to ask. The Site’s API ID is on the general settings tab and is safe to share publicly.
Ah. Well, I am hitting that use case, as my configured production branch in Netlify is indeed dev (this will change. It’s a result of … Actually, long story, doesn’t matter.).
I’m happy this is not a “real” bug affecting many users’ sites!
Can you explain the rationale behind this behavior?
Why would the coincidence of setting the alias to be the same name as the production branch name cause the deployment to be published to prod? It seems to me that those two strings should not be functionally related.
If anything though, this behavior should be well documented in the CLI deploy command, on the alias flag.
The alias is intended to deploy “as” the branchname; you chose the prod branch, we deployed “as” prod. That’s how the feature was designed.
Using it to override existing branches is fraught with peril, so at a high level, we’d recommend avoiding it. You are the only person to run into this so far and we released the --alias feature months ago, so I think it is probably not worth being loud about as we don’t want to put a ton of output that is not relevant to everyone else
I’ll ask our docs team to look at updating our documentation relating to this.
I think I understand what you’re saying, but honestly I find it cognitively confusing. The alias flag was renamed to from the branch flag, and the branch flag is now deprecated. Your explanation makes sense if you think about it as if the flag is named branch because then I could say “well I’m deploying the branch which I have defined as my production branch so I expect it to go to prod”. But if the flag is named alias and the documentation says that this is useful in order to create a more predictable preview URL, then the association between that and what I chose to be the production branch is gone.
Essentially they’re still an implicit connection between “alias” and git branches.
Having said that, this behavior simplifies my ci action, I can simply never use the prod flag and always rely on the value of the alias flag to decide whether or not to deploy to production.
I guess that might bring the question if there isn’t some overlap here with functionality, and it’s worth thinking about the miscommunication that deploying to production is possible without the prod flag.
