Rowena Foo whatupfoo

aws elb describe-load-balancers --load-balancer-name [elb-name]

aws elb create-load-balancer-policy --load-balancer-name [elb-name] --policy-name my-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true

aws elb set-load-balancer-policies-for-backend-server --load-balancer-name [elb-name] --instance-port 23 --policy-names my-ProxyProtocol-policy

aws elb set-load-balancer-policies-for-backend-server --load-balancer-name [elb-name] --instance-port 81 --policy-names my-ProxyProtocol-policy

aws elb set-load-balancer-policies-for-backend-server --load-balancer-name [elb-name] --instance-port 444 --policy-names my-ProxyProtocol-policy

Organization archetypes

The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.

1. A single organization with direct organization membership for repository access (not teams)

          ________________
          |     Org      |
          |    ______    |
          |   |      |\  |

| | Repo | \ |

Git Flow

Read more about this workflow here

Key Features

Two main long-living branches: main and develop
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop.

Tree-less & Blob-less clones

#worfklow

Get up to speed with partial clone and shallow clone - The GitHub Blog

Git clone: a data-driven study on cloning behaviors - The GitHub Blog

Treeless clones are really only helpful for automated builds when you want to quickly clone, compile a project, then throw away the repository. In environments like GitHub Actions using public runners, you want to minimize your clone time so you can spend your machine time actually building your software! Treeless clones might be an excellent option for those environments.

we do not recommend shallow clones except for builds that delete the repository immediately afterwards. Fetching from shallow clones can cause more harm than good!

	#!/usr/bin/env ruby

	# frozen_string_literal: true

	require "csv"
	require "jwt"
	require "octokit"
	require "optparse"
	require "spreadsheet"
	require "yaml"