We’re using GitHub Actions to build our apps and then Netlify CLI to deploy the artifact. We’re making use of the --alias flag to allow us to have predictable permalinks to each deploy.
This is working correctly for draft/preview deploys but when using --alias together with --prod or --prod-if-unlocked, the deploy is still a “Branch Deploy” and is not published. The CLI output suggests that the deploy should be a published production deploy but this isn’t actually what is happening.
For example, when using the following command to create a draft deploy using Netlify CLI v17.9.0:
Deploying to main site URL...
✔ Finished hashing
✔ CDN requesting 251 files
✔ Finished uploading 251 assets
✔ Deploy is live!
Build logs: https://app.netlify.com/sites/poc-fe-pipeline/deploys/6570426f036e2c54cefd12dc
Function logs: https://app.netlify.com/sites/poc-fe-pipeline/functions
Unique deploy URL: https://84052656--poc-fe-pipeline.netlify.app
Website URL: https://poc-fe-pipeline.netlify.app
but in Netlify, the deploy is shown as a “Branch Deploy” and is not published to production.
Removing the --alias from the above command results in the same CLI output and does publish the deploy.
Nothing in the documentation suggests that you can’t use the 2 arguments together and the CLI output also suggests it should be possible. Is this a bug in either the CLI or the underlying API performing the deploys or are the 2 args not able to be used together?
For one of our internal Vue.js applications, we are deploying this using the standard Netlify deployment method. As part of this we use the DEPLOY_URL environment variable for the application’s asset paths. This allows us to use the deploys permalink for assets and prevent any issues with atomic deploys interrupting our internal users’ sessions with assets changing midway through their workflows. We’re aware this prevents some of the other Netlify features from being used such as rollbacks etc but this has worked well for us so far.
As we’re moving the artifact builds to GitHub, we lose access to the DEPLOY_URL environment variable which we need to set the asset paths. We were hoping to be able to use the alias arg to be able to set the permalink URL and then use this for the asset paths at build time.
Regardless of whether this is possible, I do think there is a bug here. The CLI output is saying that a production deploy has been performed but it hasn’t.
Hi, @andypattenden. The --alias option was originally called the --branch option. However, the --alias option does not make “real” branch deploys and so this other option is deprecated (but still exists in the CLI tool last I checked).
Long story short, the --alais deploys are not currently branch deploys but they do get treated in some ways like they are. It is true that currently when deploying with the CLI that the --alias option and the --prod options do not work together. Using --alias will guarantee that the deploy is treated as non-production currently and that is the bug you experienced (and I do agree it is a bug).
You may have noticed that both uses of “currently” in the paragraph above we italicized. I did so because there is work being done to allow deploys using this option to be treated at “real” branch deploys.
Please note, as the work on this is completed, I do expect for branch deploys to become possible with the CLI tool. However, what I do not consider likely is that making branch deploys with the CLI can be production deploys - unless the branch chosen is set as the production branch. As this work is not yet completely, though, I don’t know what the final form will be when it becomes available.
For the time being, though, I can confirm that the --prod and --alias options cannot be used together successfully.
I’m looking for workaround in the meantime. The only workaround I can find is this:
Make the deploy using the --alias option but not the --prod option
After the deploy is complete use the CLI tool to make an API call to the deploy restore endpoint to publish the deploy to production
I can send example JSON to use with the restore endpoint if there are any questions about how to make the API call with the CLI tool. If more information about that would be helpful, please reply here to let us know.
Thanks for the explanation and confirmation that those args aren’t compatible with each other.
I’ve tested the workaround you’ve suggested. Although the deploy listed in Netlify is always listed as a Branch Deploy, which is to be expected, the restore step works well for what we’re doing.
It would be great if there was a more official way to do this but appreciate we’re probably an exception to how others are deploying.