submodules suck - but is it in the right place about yari HOT 5 CLOSED

Either way, I think .travis.yml in stumptown-content should see if the packaged stuff will work with the renderer. But when/if it does so, does it not matter which version of stumptown-renderer gets used? We could just assume master and do git clone https://github.com/mdn/stumptown-renderer but that gives us no ability to land things in stumptown-renderer gently.

If you're tracking stumptown-content (e.g. you're VSCode) and don't care about MDN all of this linkage might just be confusing and weird. It also slightly violates the principle that one of the consumers is engrossed inside the stumptown-content repo.

from yari.

The more I think about, the more I think we should consider a third-party approach.
We can build a piece of Python code that runs on Heroku and is triggered by Webhooks.
It can be informed when a pull request is made or updated and it can probably be informed when its CI test suite passes. Then, from there, it can do whatever it needs to do. Either way, somewhere someone needs to say "This version of stumptown-renderer works with this version of stumptown-content" or "This version of stumptown-content works with this version of stumptown-renderer".

from yari.

I've been thinking some more about this. Not so much about git submodules but how we'd deploy.
What's clear is that deployment most probably means:

1. Take a branch, run make deployment-build, and upload all the static assets and all the built index.html files etc. to S3.
2. Create a CDN distribution in front of that S3 bucket.
3. The ability to "get-or-create" S3 buckets and files and also get-or-create of CloudFront distributions.
4. It should be triggered either as GitHub Webhooks or as a final step in some .travis.yml file.
5. Some ability to control whether to bother (e.g. don't build if only the README is edited or if it's a PR from an untrusted github user)
6. Devs should be able to manually trigger builds from their laptops. Useful for debugging the tool itself and when working on some very experimental feature that isn't ready to be a PR under review.

Python has great tooling for building integrations with AWS. I.e. boto3 but it might be worth using Docker here to wrap up everything so then it doesn't matter what programming language we use.

Whatever it is we should wrap it up nicely. For example, imaging this at the bottom of a .travis.yml file (assuming all the linting and stuff worked):

...
set -x

make deployment-build
pip install stumptown-deployer 
stumptown-deployer --site=client/build --branch=$TRAVIS_BRANCH --publish-github-comment=$TRAVIS_GITHUB_PR_ID --on-error=$SENTRY_DSN

It could take care of everything. S3 buckets, syncing files (using threads!), posting a GitHub PR comment about the built website.

CC @escattone

from yari.

Also, suppose that stumtown-renderer uses the strategy of dumping Kuma MySQL content to .json files to provide the fallback when stumptown-content hasn't made the conversion yet. If that's the case we should, from Kuma periodically, ship all of that to S3. That means the pseudo code above could be something like this instead:

set -x

export STUMPTOWN_LEGACY_DOCS=./kumadocs
stumptown-deployer synclegacycontent --destination=$STUMPTOWN_LEGACY_DOCS
make deployment-build # (it would now read from stumptown/packaged *and* from `$STUMPTOWN_LEGACY_DOCS` to build the whole site)
...

from yari.

Note-to-self: https://docs.google.com/document/d/1CCacU0MGVcJXLB0Fp0k8t6PNuWsFC6cLR3XeO1jiVQU/edit

from yari.