ProjectScaffold icon indicating copy to clipboard operation
ProjectScaffold copied to clipboard

Docs output in master or gh-pages

Open forki opened this issue 8 years ago • 8 comments

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

forki avatar Jun 28 '17 15:06 forki

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).

pblasucci avatar Jun 28 '17 15:06 pblasucci

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.

Krzysztof-Cieslak avatar Jul 07 '17 22:07 Krzysztof-Cieslak

I think we should roll back

Am 08.07.2017 12:14 vorm. schrieb "Krzysztof Cieślak" < [email protected]>:

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 .

forki avatar Jul 08 '17 07:07 forki

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?

gusty avatar Oct 21 '17 17:10 gusty

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

jackfoxy avatar Oct 22 '17 01:10 jackfoxy

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

jackfoxy avatar May 26 '18 16:05 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 avatar May 26 '18 17:05 jackfoxy

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

jackfoxy avatar Jun 09 '18 17:06 jackfoxy