Instantly share code, notes, and snippets.

View createashardedmongodbincosmosdb.sh
#!/bin/bash
resourceGroupName="cosmosdbshardedtest"
name="mongodboncosmosdb"
databaseName="mongodb"
collectionName="mongodbcoll"
kind="MongoDB"
partition="/'\$v'/YourShardID/'\$v'"
az login
View Example log
Start-Date: 2018-11-19 14:23:29
Commandline: apt-get -y install less vim
Install: vim-common:amd64 (2:8.0.0197-4+deb9u1, automatic), vim-runtime:amd64 (2:8.0.0197-4+deb9u1, automatic), vim:amd64 (2:8.0.0197-4+deb9u1), xxd:amd64 (2:8.0.0197-4+deb9u1, automatic), libgpm2:amd64 (1.20.4-6.2+b1, automatic), less:amd64 (481-2.1)
End-Date: 2018-11-19 14:23:37
Start-Date: 2018-11-19 14:25:58
Commandline: apt-get remove vim
Remove: vim:amd64 (2:8.0.0197-4+deb9u1)
End-Date: 2018-11-19 14:25:59
View fluent-filebeat-comparison.md

Fluent-bit rocks

A short survey of log collection options and why you picked the wrong one. 😜

Who am I? Where am I from?

I'm Steve Coffman and I work at Ithaka. We do JStor (academic journals) and other stuff. How big is it?

Number what it means
101,332,633 unique visitors in 2017
View kill_deploy_jobs.groovy
import hudson.model.*
def q = Jenkins.instance.queue
q.items.each {
if (it =~ /deploy-to/) {
q.cancel(it.task)
}
}
View groovy.groovy
def cmd = 'hostname'
def sout = new StringBuffer(), serr = new StringBuffer()
def proc = cmd.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println sout
View pr_etiquette.md

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.

View README-oneshot-systemd-service.md

README

Services declared as oneshot are expected to take some action and exit immediatelly (thus, they are not really services, no running processes remain). A common pattern for these type of service is to be defined by a setup and a teardown action.

Let's create a example foo service that when started creates a file, and when stopped it deletes it.

Define setup/teardown actions

Create executable file /opt/foo/setup-foo.sh:

View pd-event.sh
#!/bin/bash
CONTENT_TYPE="application/json"
DESCRIPTION="bad things™ are happening"
URL="https://events.pagerduty.com/generic/2010-04-15/create_event.json"
if [ $# -ne 3 ]; then
echo "Usage: pd-event.sh [TYPE] [SERVICE KEY] [INCIDENT KEY]"
echo " - TYPE: [t]rigger | [a]cknowledge | [r]esolve"
echo " - SERVICE KEY: unique identifier for service"
View cleanup.py
"""
Code adapted from and inspired by http://blog.ranman.org/cleaning-up-aws-with-boto3/.
"""
import os
import re
from datetime import datetime, timedelta
import boto3
View Get Jenkins GDSL working with IntelliJ IDEA
1. Setup a project
2. Add groovy SDK support:
https://www.bonusbits.com/wiki/HowTo:Add_Groovy_SDK_to_IntelliJ_IDEA
3. Download http://(yourjenkinsurl)/job/(yourpipelinejob)/pipeline-syntax/gdsl
- this will give you the .gdsl file - download this to the src folder of your project.
4. Finally follow this step - right click on the src folder -> Mark directory as -> Sources Root