Docs output in master or gh-pages

[forki]

Recently we changed the scaffold to use a different workflow for docs output.

Earlier we committed the docs into gh-pages brach so that github would display it from there. Now we commit the output directly to master.

I am very worried about that change since I fear this will lead to big merge conflicts in scenarios where we support multiple release branches or when different user release.

The original script avoided this because users integrated via master and gh-pages was only an automated step.

/cc @dsyme @pblasucci @isaacabraham @sergey-tihon @Krzysztof-Cieslak

[pblasucci]

I've not used ProjectScaffold for quite some time, so I don't have any direct feedback (yet... though personal life is taking me out of the community for a bit).

But I'll observe that I share @forki concern about excessive merge conflicts. On the other hand, I wonder if this helps make ProjectScaffold easier to use on other platforms (GitLab, VSTS, etc.)?

At any rate, I think this should be watched closely. And I'm very eager to hear what others think (or better: experiences using it).

[Krzysztof-Cieslak]

I think having docs output in the main branch is terrible idea. It makes stuff harder to merge, creates gigantic diffs, makes repo harder to maintain. Also, in my view, docs output is just release artifact same as compiled .exe and usually no one commits those.

Can't say for other providers but on GitLab there is no need of committing docs output to get GitLab Pages working - GitLab Pages are using system based on integrated CI platform, and as long as docs is buildable on docker there will be no problem with getting them work.

[forki]

I think we should roll back

Am 08.07.2017 12:14 vorm. schrieb "Krzysztof Cieślak" < notifications@github.com>:

I think having docs output in the main branch is terrible idea. It makes stuff harder to merge, creates gigantic diffs, makes repo harder to maintain. Also, in my view, docs output is just release artifact same as compiled .exe and usually no one commits those.

Can't say for other providers but on GitLab there is no need of committing docs output to get GitLab Pages working - GitLab Pages are using system based on integrated CI platform, and as long as docs is buildable on docker there will be no problem with getting them work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fsprojects/ProjectScaffold/issues/304#issuecomment-313805608, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNIgi7WuGVll1fXbi6EpbaN-4gga2ks5sLq3igaJpZM4OIIdF .

[gusty]

I think we should rollback, but it might be because I still don't understand what is the equivalent of build ReleaseDocs now.

What about letting the user choose which model to use by asking him in the first run?

[jackfoxy]

https://github.com/fsprojects/ProjectScaffold/commit/265feb09e193c008db95cb8d5d768243740b655c#commitcomment-25112624

[jackfoxy]

Happy to accept a PR that give user choice at initial build.

[jackfoxy]

more background in this issue https://github.com/fsprojects/ProjectScaffold/issues/201 which I am closing in favor of keeping the discussion open here

[jackfoxy]

changing name of issue and labeling help wanted accepting PR to make configurable at init time