-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat(ng-deploy): add option for buildTarget #2063
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This makes sense. Maybe call the option environment? The advanced use case in the More Thoughts section we can plan in the future. |
I have started a discussion here about this topic. It would be great if we could find a common approach so that the expected behaviour and usability of the different builders are consistent. Currently, there could be a majority for the following options:
|
|
In the CLI, this same option is called
"deploy": {
"builder": "@deploy:deploy-builder",
"options": {
"buildTarget": "project:browser"
},
"configurations": {
"staging": {
"buildTarget": "project:browser:staging"
}
}
}, Example ng deploy --configurations staging |
@alan-agius4 safe to close this? |
Looks like it was addressed by #2063. So this can be closed. |
When I do a deployment to staging, I need two things to happen
PR #2063 only covers 1 as far as I can tell. The deploy docs are out dated and low on details. |
For now, it seems to always pick the first entry in the But that's too fragile, so I'm just going to use something like the following and avoid "deploy": "npm run build:staging && firebase use staging && firebase deploy --only hosting",
"deploy:prod": "npm run build:prod && firebase use production && firebase deploy --only hosting", |
Just a heads up - I submitted a PR to allow configuring the firebase project deploy target as well. These can be actual projects or aliases you set up via the CLI or |
And to finally make this possible, I've made a bug/feature request at the CLI end: angular/angular-cli#17332 This is to enable using the |
Seems like this is now implemented?
|
More options dropped in |
Current Behavior
Right now, the
@angular/fire:deploy
builder infers the build target to betargetProject:build:production
. This makes it impossible to deploytargetProject:build:staging
which may have different environment variables etc.Expected Behavior
Option 1
Add an option for
buildTarget
so that the fulltargetProject:build:staging
can be passed in and scheduled.Personally, since schematics can generate the config via
ng add
orng generate
, I would opt for this one.Option 2
Add an option for
configuration
so thatstaging
can be passed in andtargetProject:build:staging
can be scheduled.More Thoughts
Inferring the build target is okay, but I would rather not schedule anything at all if I leave it blank so a user can build separately ahead of time in the case Firebase Functions are someday supported. :)
Caveat
This configuration information might be important for knowing which Firebase project/ target to deploy to. This might be better done in a separate option.
The text was updated successfully, but these errors were encountered: