2018-10-11 Notes

home / log / 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.


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


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


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


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