Have the app download the right data on startup. If that fails it won't
start the app and so the deployment will fail, but the existing
deployment will stay up.
* Move from django-pipeline to Gulp for static-assets
* Use Gulp tasks to compile less and sass
* Use Gulp tasks to concatinate files into bundles
* Use Gulp tasks to minify files for deployment
* Use Gulp tasks for development to watch for changes
* Use BrowserSync to serve development static files and refresh the
in-progress page
* Update Docker setup to use multi-stage build
* Update Makefile to build and run the docker setup
* Update docs to recommend Docker-based development
* Update deployment and testing to also use the Makefile
* Add rebuild of SASS bundles when library files change
* Add an intermediate build directory just for LESS and SASS
* Avoid issues with ambiguous imports when .css and .scss in the same
directory
* Set deployment docker image in git env var script
A.K.A The Sqlitening!
This removes bedrock's depenence on a database server and moves to
downloading pre-built sqlite database files from s3 on a schedule. There
is also a clock process that will update and upload such a database on a
schedule as well. This should mean more stability, speed, and
reliability for bedrock, as well as quicker development due to easy to
download pre-populated databases.
* Revert "Fix container names in integration tests (#5386)"
This reverts commit aec7d9ca7b.
* Revert "Use branch name in test container names; avoid conflicts (#5385)"
This reverts commit 24abfb303d.
If you try a deployment of two branches with the same commit
(e.g. master and prod) it will often fail due to conflicting
container names when they were just using commit hash. Adding
the branch name should eliminate these failures.
* No longer rely on release notes JSON files on the file system.
* Switch everything to new update_release_notes_data command
* Move to using django-memoize for releasenotes caching
Will allow us to simplify bedrock by not installing RNA.
Remove:
* django-mozilla-rna
* django-restframework
* django-synctool
Do markdown conversion on load of release: Helps with cache and perf.
Add tests for new release models
Add a management command to generate a sitemap and update deployment
to generate and include it in the builds.
Thanks to @kyoshino in PR #1333 for most of the basis of this work.
* Fix demo deploy and update docs.
* Make it work with deis1 and deis2
* Enforce max 63 char app names
* Fix SSL redirect for Deis v2 clusters. Allow settings per cluster.
* Improve env file handling and combination for demo deploys
* Use new envcat utility
* Deploy our dev, stage, and prod apps to virginia and tokyo clusters
Turns out LinkChecker checks for a good version of python-requests
in a dumb way, so it sees version "2.13.0" as being lower than
"2.2.0". Also the project seems to have been abandoned, so there
isn't a newer release, though it seems this issue has been fixed
in the master branch.
Easiest fix is to just downgrade requests to the latest version
that is < 2.10.0, which is what I've done.
This means that we can push dev l10n to www-dev and prod
l10n to stage and prod. Currently they all get prod l10n
at deployment then dev updates when cron runs.
The content of the hashed CSS files is different from the
non-hashed versions. In the former the references to other
files (e.g. images) have been changed to their hashed versions.
We want to keep these versions since they are served with far-future
cache headers and thus reduce our server loads.
* Don't include git directory.
* Build bedrock_base
* Build bedrock_code
* Update run_tests
* Build bedrock_l10n
* Update push to docker hub.
* Update push2deis
* bedrock_l10n: When time triggered use the currently deployed commit.
* Script to check if commit is tag.
* Skip docker image squashing if not needed.
* Allow pulling base docker images.
* Build only if commit in master branch or commit is tagged.
Paul McLanahan
Alex Gibson
Giorgos Logiotatidis
Josh Mize
Chris Beaven
Josh Mize
Paul McLanahan
alexgibson