-
Notifications
You must be signed in to change notification settings - Fork 56
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
Fix up CI doco toolchain - migrate to VuePress #1116
Comments
After some research, the following learnings and path forward are suggested. In a nutshell, we are ditching any custom or heavily customized solutions for web sites and documentation.
Current progress expands original ticket description. Main change is ditching Roslyn, removing all custom code, and moving all source code examples back into markdown files. ETA is around 2 weeks, mid-June, to move current POCs into public github projects, setup CI and migrate content. Partly, most of the tasks (apart content migration) were already implemented in NET/C#/AppVeyor and need only re-implementation under new environment - Docker/Travis CI. Content migration is the heaviest, manual process. Current progress
|
…yam, choose off the shelf solution #1116
Current progress on 11/06/2018 POC is completed under dev-1116 branch in doco repo:
Works on both windows/mac platforms, uses AppVeyor CI for continuous publishing . Ruby scripts heavy lift build orchestration, Vagrant/Docker and AppVeyor ensures portability and CI:
vuepress provides rich features around navigation, edit on github links, search and many others. So far, we use zero customization. Currently, the content looks ugly - not all content was portend, not much navigation was setup, and then code samples have to be moved as well (further content migration work)
AppVeyor buillds:
Outstanding work is more of a routine doco migration and content writing:
Pre-Content migration scope
|
|
dev-1116 branch -> dev site -> https://subpoint-docs-vuepress-dev.netlify.com/ build.yaml drives repository setup. Publishing trigger might be either dev -> beta branch move on the source repository or manual trigger on beta/master branch of docs repository, that's in discussion. This ends technical milestone leaving open only non-technical content migration across 6 repos + newly added metabox (7 in total). Content migration scope
|
Currently, SPMeta2 uses a custom tailored, Wyam based workflow to generate documentation across several projects. This approach proven to be ineffective, complex and slow.
This is very similar to blog platform problem - instead of reinventing the wheel, an appropriate solution such as Medium better be used.
Here is the current state:
Pretty much, we should be focusing on projects rather than on crafting custom engines for project documentation. All non-tech work, such as blog, doco and so on should be outsourced to the right platform or tool.
As a solution, the following changes are proposed:
Using an off the shelve solution for documentation is the right way in out situation. As for the projects, a few stages are proposed:
use generated C# sample index with the next Docker container within middleman, jekyll, hexo, vuepress or other static site generatorThis work should take priority so that we would be able to maintain a consistent, easy-to-edit and up to date doco.
The text was updated successfully, but these errors were encountered: