Provision to use options `add` and `dest` in schema.json

[richierich25]

Is there a way we can use the add option to only allow modified files to be written to the gh-pages branch? This feature is available in gh-pages

Since I want to host multiple angular projects from the same github repository, whenever I run the ng deploy it creates a fresh output.

On similar lines, I wanted to use the dest option to ensure that all commits to gh-pages branch occur on the respective project (/project-name/All-files) and not on the root directory (/All-files).

Any workaround or guidance will really help!

[JohannesHoppe]

Hmm... I see your point. Are you sure, that you really would want to use the add option? Productive angular bundles have hashes in the filenames, so that they are unique. You would end up in multiple version of the bundles in the same folder. That's why I decided angular-cli-ghpages to always start fresh.

But you are right, the new ng deploy interface lacks the --dir option because it was clearly made with one project per deployment in mind. This is generally a problem with all ng deploy schematics, they are designed for the deployment of one project only.

Recommended solution:

1. Building all projects as you would do normally
2. Use the standalone programm with --dir, see https://github.com/angular-schule/angular-cli-ghpages/blob/master/docs/README_standalone.md

Generally I'm not sure if there is a perfect solution for your setup. IMHO ng deploy was not designed for the deployment of multiples projects. Exactly for this advanced scenarios we have kept the old standalone version. Internally we use the standalone program for all kinds of deployments, even non-angular! 😎

[richierich25]

My workaround for working with Multi-projects in a single Repository:

1. I have updated the schema.json within the node_modules by appending the options with default values for add: true and dest: project1.

• add - to allow adding new Project directories (/project1, /project2, ...) at root of gh-pages branch for each project without removing existing published files
• dest - to specify the name(project1, project2) of the output folder in which the respective files can be published into.

2. And then I would perform the regular ng deploy for each project. This allows for each project to be published independently and allow custom names. I know this is tedious, but I could think of nothing better

As you mentioned correctly, add option causes multiple hashed file names to be present. (Currently manually removing the project (/project1) from the gh-pages branch in case the hashed files have changed)

I believe with standalone program, you mean using $npx angular-cli-ghpages --dir=dist/, but the issue is it is creating the gh-pages afresh. (It will remove all the other projects code and only publish only the recent one). Also the 404.html is not created as it does not consider dist/ as a valid angular cli project.

Is there a way I could use the standalone program in a way that would not create a new instance of gh-pages each time? This will help me to avoid editing the schema.json and make it much simpler.

Thank you once again.

[JohannesHoppe]

Yes, I would suggest that you compile everything before, so that all projects are in the dist folder. Then you do a npx angular-cli-ghpages --dir=dist/ and everything done.

[richierich25]

Alright. but the issue is if i do that then it is creating the gh-pages afresh. (It will remove all the other projects code and only publish only the recent one). Also the 404.html is not created as it does not consider dist/ as a valid angular cli project.

[JohannesHoppe]

Ok, I will re-introduce the --dir option again. 🙂👍

[Hypercubed]

I see this issue is still open. Has there been any discussion on adding the dest option?

(to the standalone program at least)

[JohannesHoppe]

I added a --dir option in angular-cli-ghpages@2.0.0-beta.1. Please try out this version and give me feedback.

This option overrides the directory for all published sources, relative to the current working directory. The normal logic with buildTargets and conventions is ignored in this case.

See #179

Do you still need dest and add, if yes, please comment here so that I can reopen this issue! 👍