❌ deprecated [RFC] A deployment builder must always compile the project before the deployment

[JohannesHoppe]

Based on Minkos statement I suggest that we all

1. always compile in production by default
   • or with another configuration by the use of the Option --configuration
2. and after that deploy to the target

Example:

ngx-deploy-starter/src/deploy/actions.ts

Lines 25 to 29 in 463290b

	const build = await context.scheduleTarget({
	target: 'build',
	project: context.target.project,
	configuration
	}, overrides as json.JsonObject);

TODO:
Discuss / find a unified solution with all other maintainers of the existing deployment builders.

---

See also:
Azure/ng-deploy-azure#23

FYI
@jamesdaniels @mgechev @johnpapa @santoshyadav198613 @shmool @huv1k @fmalcher

[santoshyadavdev]

I am also using the same, so the config can be overwritten, but a great initiative. As of now in our case, we are rebuilding every time before deploy.

I liked the option 3 from @johnpapa we can give users an option if they want to rebuild it.

[fmalcher]

I agree 100%! We can't make sure that developers always remember to build the app before deploying it. Thus, the build must be part of the deployment step to avoid deploying broken stuff that hangs around in our dist.
I'd like to see an opt-out via command-line option (--no-build?) which can be used when I'm sure I havent changed anything and want to deploy again.

tl;dr;

• Yes, always build before
• but give the opportunity to opt-out
• opt-out should not come through a wizard, but only as an explicit cmd option

[huv1k]

Our deployment builder always builds the source before actual deployment too. I find it natural to do it like this for the developer.

[JohannesHoppe]

Ok, @fmalcher so you are voting for --configuration AND --no-build (for the people who really, really know what they are asking for)?

I can agree to that.

[fmalcher]

@JohannesHoppe Yes!

[JohannesHoppe]

Ladies and gentlemen: Lets agree to this:

• --configuration (alias -c): A named build target, as specified in the "configurations" section of angular.json
• --no-build: Skip build process during deployment

State of Progress

• @huv1k from @zeit/ng-deploy added --configuration (alias -c) and --no-build in v0.2.1 👍
• @santoshyadav198613 from @netlify-builder/deploy already added --configuration but not --no-build.
• I will add --configuration (alias -c) and --no-build for the next version of angular-cli-ghpages.

Call for action

❌ @angular/fire (@jamesdaniels are you in?, see angular/angularfire#2063)
❌ @azure/ng-deploy (@shmool are you in?, see Azure/ng-deploy-azure#23)
☑️ @netlify-builder/deploy (@santoshyadav198613 are you in?, see ngx-builders/netlify-builder#33)
✅ @zeit/ng-deploy (@huv1k implemented this in v0.2.1)
✅ angular-cli-ghpages (implemented in v0.6.0)

[george43g]

It took me to actually go through some of the committed code to understand exactly what was going on - so the --configuration flag is being added here to determine which configuration is used to build the project, not to specify a deploy target.

I think that's a mistake. The ng deploy command might have several of its own configurations, in which case the behavior of the --configuration flag should allow the user to choose production, development, staging, qa, etc... - each configuration will then tell the deploy builder two things:

1. Which build target to use, which defines the build configuration (production, local, etc)
2. Which environment to deploy the project to (qa, staging, production, dev, etc...)

There may be various such combinations.

I'm unsure wether angular cli doesn't recognise the --configuration flag by design or not. But because of this, this has allowed --configuration to be used as a custom option in one of the commits here. Meaning that if the CLI now starts to recognise --configuration in the same way it does with serve and build targets, it will break some of the above code :(

[george43g]

angular/angular-cli#17332

Just a heads up, this bugfix might break the --configuration flag used by several of the above deployment builders.

[JohannesHoppe]

@george43g Thank you for your feedback. I fully agree with your objection. For my projects I have already renamed the option configuration to buildTarget . I will try to bring all other projects back in sync as well.

See

• feat: add support for Angular v11 (follow up) angular-cli-ghpages#120
• feat: add support for Angular v11 #25