2018-10-11 Notes

open source terraform. - move to terraform subdir in main repo? - move to new repo?

it would be good to not slow down the main project build with the ops website build. can we move the ops website to a different repo and trigger the build from the main repo build? we can allow parallel builds again in the main project, but limit ops website repo to max 1 parallel. or mark the build done while the ops website stage run happens.

• sync ops data bucket to ops-website/content/
• renamed .yml to .md
• build and observe. what else needs to be added to the transform?
• then iterate on single templates
• link latest items of each type on index html
• first summaries/reports on index page?

• what data fields are we missing still? classes of fields?

• site content changes

  • turn distance adjustments for double bend tracks
  • speed rating normalization
  • speed badges

Next

Uptimerobot RSS feed to laps.run tweet on outage

Single twitter handle.

Google analytics for ops site.

Trends in build/deploy data. Don’t do it over relative time (last week, vs this week). Do it last 10 vs prev 10. Show time span for each.

Will probably need to look into pagination for build list because of high quantity. Hold off as long as possible

Trigger builds via Travis api. https://docs.travis-ci.com/user/triggering-builds/

Make sure I can isolate how much time was spent sending metrics, ideally collecting metrics

Monday

I made Deploy the base branch for ops.laps.run. The reasoning behind that is I have a theory that Travis treats master specially. I set max concurrency to 1. I want Travis to cancel any queued builds on the deploy branch. I only build on the deploy branch, using an allow list in Travis.yml. I couldn’t test my theory because I’m capped at 10 Travis api calls per hour. If it treats deploy like master because it is the base branch, I can revert it to use master as the base branch, then keep deploy as my build branch. Test if I get the behavior I want. If not just use master only as both the base and build branch.

I also turned on a daily build which will run a build if no activity in the previous day. I think this might cover cases where there is a flurry of activity that all gets cancelled.

I think I need to think through this some more. I want debounce basically

Tuesday

The sha of the ops repo is worth noting but not that interesting. Linking to the build number of the main repo and a timestamp of the build is more important

Thursday

• change ops repo back to master from deploy as mainline-trunk
• Git ignored data directory separate from content/ for pulling and cacheing yaml files from s3
• Update transform commands for source and destination directories
• Cache data directories in Travis to limit repulling data from s3
• Do not cache content/ or public/. Rebuild those every build
• Portable data pull and transform for ops site setup
• Index.html latest events list
• Single templates
• Build
• Preview deploy
• Prod deploy
• First aggregations

Google analytics for ops website behind production deploy Consider changing ops deploy to a custom s3 sync command with —delete Consider changing www deploys to custom s3 sync command with —delete Ops: With cache on the s3 data directories enabled, consider enabling the build for all branches

Activity data on the bucket storing the build data. Read activity in particular should be improved by enabling the Travis cache

• change ops repo back to master from deploy as mainline-trunk
• Git ignored data directory separate from content/ for pulling and cacheing yaml files from s3
• Update transform commands for source and destination directories
• Cache data directories in Travis to limit repulling data from s3
• Do not cache content/ or public/. Rebuild those every build
• Portable data pull and transform for ops site setup
• Index.html latest events list
• default single template

• [x] First aggregations

• [x] link from main website to ops

• [x] Uptime robot link/badge to ops website.

• [x] link from ops website to main

• [x] Google analytics for ops site.

Next:

• Uptimerobot RSS feed to laps.run tweet on outage. Single twitter handle.
• Trends in build/deploy data. Don’t do it over relative time (last week, vs this week). Do it last 10 vs prev 10. Show time span for each.
• add custom single data per type, highlighting data available.
• add duration/timeline to all types
• link build from deploys
• link deploy from build
• link to github from build
• link to travis from build
• open source terraform