schacon

$ git branch -r --merged | 
  grep origin | 
  grep -v '>' | 
  grep -v master | 
  xargs -L1 | 
  awk '{split($0,a,"/"); print a[2]}' | 
  xargs git push origin --delete

mitchellh

Vagrant::Config.run do |config|
  # ...

  config.vm.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end

fujin

#!/usr/bin/env ruby

cbdir=ARGV[0]
output = "./deps.dot"

puts "Running on #{cbdir}..."

cb_meta = Dir.glob("#{cbdir}/*/metadata.rb")

fp=File.open(output,"w")

jtimberman

This is idea brainstorming for a community plugin for releasing cookbooks per Opscode's current process. This would replace the functionality of the "cookbook site share" plugin that is built into Chef, as I believe the cookbook site plugins should use "community" rather than "cookbook site" and be a separate plugin instead of built into Chef and tied to its release cycle.

knife community release COOKBOOK VERSION

Assumes that the repository is release ready, e.g., the current HEAD is the commit that should be released, CHANGELOG is updated already, etc.

1. sets metadata version to the specified VERSION
2. makes a git commit with the release VERSION in the metadata
3. creates a git tag with the bare version, e.g. "1.0.1" not "v1.0.2"
4. pushes to the opscode (or other upstream as apropos) master branch, takes --remote argument as alternate, and pushes git tags

alq666

require 'rubygems'
require 'dogapi'

# Create a simple client
# The host is optional here, it's a shortcut to tie event and metrics to a given host
#
# You typically want to do:
#   Dogapi::Client.new(your_actual_api_key_as_a_string, ...)
# We are using ENV to let you experiment via an environment variable.
dog = Dogapi::Client.new(ENV['DATADOG_KEY'])

tobert

# save some memory on indexes
index_interval: 512

# this can hurt your read latency, but in my experience it's better to stay caught up
compaction_throughput_mb_per_sec: 0

# if you have lots & lots of connections, e.g. from Hadoop, saves memory
rpc_server_type: hsha

jayjanssen

net.core.somaxconn = 32768
net.ipv4.conf.all.send_redirects = 1
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_mem = 200000    280000    300000

fnichol

SUITE_NAME=default

# create a bats subdirectory under your desired suite
mkdir -p test/integration/$SUITE_NAME/bats

# create an initial "canary" bats test file
# more examples at:
# * https://github.com/fnichol/chef-rvm/tree/master/test/integration/rubies/bats
# * https://github.com/fnichol/chef-ruby_build/tree/master/test/integration/alltherubies/bats
# * https://github.com/sstephenson/bats

nzakas

I'm doing some research on how companies use GitHub Enterprise (or public GitHub) internally. If you can help out by answering a few questions, I'd greatly appreciate it.

1. What is the primary setup? Is there an organization and each official repo is owned by that organization?
2. Does every engineer have a fork of each repo they're working on?
3. Are engineers allowed to push directly to the official repo? Or must all commits go through a pull request?
4. Do engineers work on feature branches on the main repo or on their own forks?
5. Do you require engineers to squash commits and rebase before merging?
6. Overall, what is the workflow for getting a new commit into the main repository?
7. What sort of hooks do you make use of?
8. Are there any ops issues you encountered? (Scaling, unforeseen downtime, etc.)

tobert

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.ip_forward=0
net.ipv6.conf.all.forwarding=0
kernel.sysrq = 1
kernel.panic = 300
fs.file-max = 1048576
kernel.pid_max = 999999
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 65536 16777216