UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Steps to reproduce the problem:
We've ported the GitHub Pages framework to our chrome-internal instance. The first example of a site is the new Chrome OS partner site: cpfe-staging.corp.google.com/docs/index.html
All the content that you see is in chrome-internal, either in chromeos/docs or chromeos/requirements
The problem is, we build manually right now. It doesn't take long and the steps are well-understood. There are shell scripts that we run interactively (not as cron jobs). Still, one of 2 people w/the software stack has to press a button.
What is the expected behavior?
Since the macro goal is distributed authoring for the Chrome OS team, we want to follow the same workflows and patterns as the OS does: regular automated builds (at least daily), versions that are aligned with CrOS milestones and use the same conventions, presubmit checks for valid YAML and MD, etc.
What went wrong?
Right after contributors walk thru the git workflow for the first time, they ask 'now how can I view what I just did'?
And the current answer is, you can't! You just toss your CL over the cliff and wait for one of 2 people with the software stack to press a button at some point. There's no predictable build/version/output. If a change does go wrong and affects the doc build, it's tough to isolate root cause because individual workstations have variable environments.
Did this work before? N/A
Chrome version: 52.0.2743.116 Channel: n/a
OS Version:
Flash Version: Shockwave Flash 22.0 r0
Comment 1 by eastrue@google.com
, Oct 4 2016