This is the website for SRCCON, the yearly conference for newsroom developers, designers, data reporters, and others who work with code in and around newsrooms.
- Clone this repository to your local machine.
- For minor updates, work directly in the
staging
branch. For major updates, or if you're working on long-term changes to the site, create a new feature branch. - To test your work locally, run
jekyll serve
orjekyll build
, and view the site in a browser.
- When you're ready to have someone review a site update, update the
staging
branch in GitHub. If you're working instaging
locally, you just need to push your code changes. If you're working in a separate feature branch, push that branch to GitHub and then open a pull request intostaging
and merge it. - NOTE: You do not need to commit updates to your local
_site
directory after you runjekyll build
orjekyll serve
. You only need to commit new or updated markdown documents and templates, and new or updated static media files. - A commit to the
staging
branch on GitHub will trigger an automatic build of the SRCCON staging site. This runs its ownjekyll build
process before copying everything to S3. (So any changes to the repo's_site
directory will be ignored.) - The Travis CI process that handles this can take a minute or two to complete. Your changes will not be visible on the staging site immediately, but they'll be there quickly.
- Review your changes on the staging site, and if everything looks OK, come back to this repo and open a pull request from
staging
intomaster
. - Merging a pull request into
master
, or pushing any commit to themaster
branch, will trigger an automatic build of the production site at srccon.org. Again, this runs its ownjekyll build
process before copying to S3, ignoring any changes to the repo's_site
directory. - The production site is delivered through Amazon CloudFront so that we can serve a secure, https-enabled srccon.org. CloudFront also caches everything for performance. The rebuild process triggers an invalidation of the entire cache, but it still may take up to 10 minutes for site changes to be reflected on production.