├── .gitignore ├── README.md ├── SECURITY.md ├── dotfiles ├── bash_profile │ ├── .bashrc_cm │ ├── bash_logout │ ├── bash_profile │ └── bashrc └── pbuild │ └── pbuild ├── gitinstall-aix.md ├── gitinstall-hp.md ├── gitinstall-linux.md ├── gitinstall-readme.md ├── gitinstall-solaris.md ├── images ├── MobAgent-Key-List.jpg ├── MobaXterm-Configuration.jpg └── macosx-AppStore.png ├── msft-bin ├── addme ├── arch ├── getkits.sh ├── installkits.sh ├── mount-builds.sh ├── mount-ostcdata.sh └── removekits.sh ├── network-resources.md ├── setup-MobaXterm.md ├── setup-build.md ├── setup-builddeps.md ├── setup-buildhosts.md ├── setup-git.md ├── setup-macosx.md ├── setup-pbuild.md ├── setup-rules.md ├── setup-sshkeys.md ├── tfs-migration.md ├── workflow-branching.md ├── workflow-hotfix.md ├── workflow-tagging.md └── workflow-workflow.md /.gitignore: -------------------------------------------------------------------------------- 1 | # .gitignore file for documentation 2 | 3 | *~ 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## ⚠️ Deprecation & Archiving Notice ⚠️ 2 | 3 | Thank you for your support and contributions to **ostc-docs**. 4 | 5 | This repository is now **deprecated** and will be **archived soon**. 6 | 7 | - **No further development, maintenance, or updates** will be provided. 8 | - **Bug fixes, security patches, and feature enhancements** are no longer planned. 9 | - After archiving, this repository will remain **available in read-only mode** for reference. 10 | 11 | We encourage users to explore alternative solutions, as this project will no longer be actively maintained. 12 | 13 | For any questions, please refer to the existing documentation or community discussions. 14 | 15 | --- 16 | # ostc-docs 17 | 18 | Documentation for the Open Source Technology Center (OSTC) team. 19 | 20 | Please note that this is a public repository, and I'd like to keep it 21 | public so other public repositories can refer to sections of this 22 | repository. This avoids duplication of documentation, which helps 23 | avoids repository documentation becoming stale over time. 24 | 25 | Experience dictates that this repository is useful for multiple 26 | groups. To maintain this, the very first section, Infrastructure 27 | Information, is dedicated to OSTC-specific information. All other 28 | sections are intended to be generally useful for everyone. 29 | 30 | Please keep this in mind when adding documentation to this repository. 31 | 32 | ----- 33 | 34 | New to git? See [Guidelines for development](setup-rules.md), which 35 | has useful links on how to use git. 36 | 37 | ----- 38 | 39 | 1. Infrastructure Information 40 | 1. [Useful Network Resources](network-resources.md) 41 | 2. [Build Hosts](setup-buildhosts.md) 42 | 3. [Build System Dependencies](setup-builddeps.md) 43 | 4. Development Hosts 44 | 5. [Migrating from TFS](tfs-migration.md) 45 | 6. [Set up Hyper-V DNS configuration](https://github.com/jeffaco/msft-updatedns) 46 | 7. [Installing git on UNIX/Linux](gitinstall-readme.md) 47 | 8. [Setting up Mac OS/X systems](setup-macosx.md) 48 | 2. Setup Instructions for Code Contributors 49 | 1. [Setting up SSH public/private keys](setup-sshkeys.md) 50 | 2. [Setting up git environment](setup-git.md) 51 | 3. [Guidelines for development](setup-rules.md) 52 | 4. [Setting up a machine for build purposes](setup-build.md) 53 | 5. [Setting up PBUILD hosts](setup-pbuild.md) 54 | 3. Workflow for Code Contributors 55 | 1. [Branching Strategy](workflow-branching.md) 56 | 2. [Workflow for Development](workflow-workflow.md) 57 | 4. Administrative Information 58 | 1. [Tagging Releases](workflow-tagging.md) 59 | 2. [Creating a Hotfix Release](workflow-hotfix.md) 60 | 61 | ----- 62 | 63 | ### Code of Conduct 64 | 65 | This project has adopted the [Microsoft Open Source Code of Conduct][]. 66 | For more information see the [Code of Conduct FAQ][] or contact 67 | [opencode@microsoft.com](mailto:opencode@microsoft.com) with any 68 | additional questions or comments. 69 | 70 | [Microsoft Open Source Code of Conduct]: https://opensource.microsoft.com/codeofconduct/ 71 | [Code of Conduct FAQ]: https://opensource.microsoft.com/codeofconduct/faq/ 72 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /dotfiles/bash_profile/.bashrc_cm: -------------------------------------------------------------------------------- 1 | # Allows ability to externalize the Windows Credential info 2 | # in order to facilitate pbuild and other environment updates... 3 | 4 | if [ -f ~/.wincred ]; then 5 | . ~/.wincred 6 | fi 7 | 8 | OSARCH="" 9 | 10 | if [ ! -x ~/bin/arch ]; then 11 | echo "No arch script found..."; 12 | else 13 | OSARCH=`~/bin/arch` 14 | fi 15 | 16 | # It turns out that if you echo during an SCP, the SCP will fail. 17 | # The good news is the TERM is set to "dumb" when SCP logs in. So 18 | # we can trap that here. 19 | if [ -n "$TERM" -a "$TERM" != "dumb" ]; then 20 | if [ -z "$WINDOWS_DOMAIN" -o -z "$WINDOWS_USERNAME" ]; then 21 | echo "Error: Please set the WINDOWS_DOMAIN and/or WINDOWS_USERNAME variables" 22 | echo "in your ~/.wincred file before attempting to configure TFS." 23 | echo "Like this..." 24 | echo "export WINDOWS_DOMAIN=MYDOMAIN" 25 | echo "export WINDOWS_USERNAME=MYUSERNAME" 26 | fi 27 | fi 28 | 29 | if [ -d ~/src/configmgr/Unix ]; then 30 | export CM_DEV_ROOT=`(cd ~/src/configmgr/Unix; pwd)` 31 | export CM_HOME=$CM_DEV_ROOT/output/`hostname | sed 's/\.scx\.com//'` 32 | export NW_HOME=$CM_HOME/nanowbem 33 | elif [ -d ~/dev/cm/configmgr/Unix ]; then 34 | export CM_DEV_ROOT=`(cd ~/dev/cm/configmgr/Unix; pwd)` 35 | export CM_HOME=$CM_DEV_ROOT/output/`hostname | sed 's/\.scx\.com//'` 36 | export NW_HOME=$CM_HOME/nanowbem 37 | fi 38 | 39 | case "$OSARCH" in 40 | SLES* ) 41 | export PATH=.:~/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/teamprise:/opt/tfprox/bin 42 | export LD_LIBRARY_PATH=$NW_HOME/lib 43 | ;; 44 | 45 | HpuxB.11* ) 46 | export PATH=.:~/bin:/opt/langtools/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/java1.5/bin:/opt/teamprise:/opt/tfprox/bin:/opt/aCC/bin:/usr/bin/X11 47 | if tty > /dev/null; then 48 | stty intr  49 | stty erase  50 | stty kill  51 | fi 52 | export SHLIB_PATH=$NW_HOME/lib 53 | ;; 54 | 55 | Aix71*|Aix61*|Aix53* ) 56 | export PATH=.:~/bin:/opt/freeware/bin:/usr/vacpp/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/opt/tfprox/bin:/opt/teamprise:/usr/java5/bin 57 | export LD_LIBRARY_PATH=$NW_HOME/lib 58 | export MANPATH=/usr/man:/usr/vacpp/man/EN_US:$MANPATH 59 | 60 | ;; 61 | 62 | RHEL6* ) 63 | export PATH=.:~/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/teamprise:/opt/tfprox/bin 64 | export LD_LIBRARY_PATH=$NW_HOME/lib 65 | ;; 66 | 67 | RHEL5*|RHEL4* ) 68 | export PATH=.:~/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/teamprise:/opt/tfprox/bin 69 | export LD_LIBRARY_PATH=$NW_HOME/lib 70 | ;; 71 | 72 | Sol10*|Sol9* ) 73 | export PATH=.:~/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/teamprise:/opt/tfprox/bin:/opt/sfw/bin:/usr/sfw/bin:/opt/SUNWspro/bin 74 | # Fix man path to include optional compiler man pages 75 | export MANPATH=/usr/man:/opt/SUNWspro/man:$MANPATH 76 | export LD_LIBRARY_PATH=$NW_HOME/lib 77 | ;; 78 | 79 | Sol11* ) 80 | export PATH=.:~/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/teamprise:/opt/tfprox/bin:/opt/sfw/bin:/usr/sfw/bin:/opt/solstudio12.2/bin 81 | # Fix man path to include optional compiler man pages 82 | export MANPATH=/usr/man:/opt/solstudio12.2/man:$MANPATH 83 | export LD_LIBRARY_PATH=$NW_HOME/lib 84 | ;; 85 | 86 | *) 87 | echo "Unknown Architecture, no path set." 88 | ;; 89 | esac 90 | 91 | 92 | -------------------------------------------------------------------------------- /dotfiles/bash_profile/bash_logout: -------------------------------------------------------------------------------- 1 | # ~/.bash_logout 2 | 3 | -------------------------------------------------------------------------------- /dotfiles/bash_profile/bash_profile: -------------------------------------------------------------------------------- 1 | # Some applications read the EDITOR variable to determine your favourite text 2 | # editor. So uncomment the line below and enter the editor of your choice :-) 3 | #export EDITOR=/usr/bin/vim 4 | #export EDITOR=/usr/bin/mcedit 5 | 6 | test -s ~/.alias && . ~/.alias || true 7 | 8 | # Getting an error when running some X-based programs: 9 | # 10 | # Couldn't connect to accessibility bus: Failed to connect to socket ... 11 | # 12 | # Apparently forwarding accessibility bus over SSH isn't supported. 13 | # Squelch the error 14 | 15 | export NO_AT_BRIDGE=1 16 | 17 | # 18 | # Set up common aliases and enviornment variables 19 | # 20 | 21 | IGNOREEOF=3 22 | 23 | # 24 | # Platform specific setup 25 | # 26 | 27 | # Save path so, if we re-run ourselves, the path doesn't get needlessly long 28 | 29 | if [ "${SAVED_PATH:-==Unset==}" = "==Unset==" ]; then 30 | export SAVED_PATH="${PATH}" 31 | else 32 | export PATH="${SAVED_PATH}" 33 | fi 34 | 35 | # Some systems have less, some don't - if we don't, just use more 36 | 37 | if ( type less > /dev/null 2>&1 ); then 38 | export LESS="-ImRs" 39 | export PAGER="less" 40 | else 41 | alias less="more" 42 | export MORE="-is" 43 | fi 44 | 45 | # For 'ls', use colors if we have them (and use LS_OPTIONS if it exists) 46 | 47 | if [ $(uname -s) = "Linux" -a -f /etc/SuSE-release ]; then 48 | if [ "${LS_OPTIONS}" != "" ]; then 49 | export LS_OPTIONS="${LS_OPTIONS} -p" 50 | else 51 | alias ls="ls -N --color=tty -T 0 -p" 52 | fi 53 | else 54 | alias ls="ls -p" 55 | fi 56 | 57 | # If Rational tools (purify & friends) are around, run initialization files 58 | # (typically installed in something like: 59 | # /opt/rational/releases/PurifyPlus.7.0.0.0-012/i386_linux2/bin) 60 | 61 | if [ -f /opt/rational/purifyplus_setup.sh ]; then 62 | source /opt/rational/purifyplus_setup.sh > /dev/null 63 | fi 64 | 65 | # Generic settings by O/S 66 | 67 | export PATH=/usr/local/bin:$PATH 68 | 69 | case `uname -s` in 70 | AIX) 71 | alias users="users | tr ' ' \"\n\" | sort -u | tr \"\n\" ' '; echo" 72 | export PATH=/opt/freeware/bin:/usr/vacpp/bin:$PATH 73 | 74 | # AIX 7.1 appears to have a low data limit, causing dbx grief 75 | [ `uname -v` -eq 7 ] && ulimit -d unlimited 76 | ;; 77 | 78 | Darwin) 79 | alias ps-scx="ps -ef | grep cim" 80 | alias users="users | tr ' ' \"\n\" | sort -u | tr \"\n\" ' '; echo" 81 | ;; 82 | 83 | HP-UX) 84 | alias users="users | tr ' ' \"\n\" | sort -u | tr \"\n\" ' '; echo" 85 | 86 | export PATH=/opt/java1.5/bin:$PATH 87 | export UNIX_STD=2003 88 | 89 | # HP utilities are very sensitive to locale, and some don't work with utf8 90 | LANG=C 91 | export LANG 92 | 93 | # Be sure we have correct version of 'make' 94 | if [ ! -f ~/bin/make ]; then 95 | mkdir -p ~/bin 96 | ln -s /usr/local/bin/gmake ~/bin/make 97 | fi 98 | export PATH=~/bin:$PATH 99 | ;; 100 | 101 | Linux) 102 | # alias ps-scx="ps aux | egrep \"cim|scx\"" 103 | alias users="users | tr ' ' \"\n\" | sort -u | tr \"\n\" ' '; echo" 104 | export PATH=$PATH:/usr/sbin 105 | 106 | export PS1="\u:\W> " 107 | ;; 108 | 109 | SunOS) 110 | # On Solaris, emacs has a wierd menu in the minibuffer; clearing LANG gets rid of it 111 | alias emacs="LANG= emacs" 112 | 113 | if [ `uname -r` == '5.8' -o `uname -r` == '5.9' ]; then 114 | alias users="who | cut -d\ -f1 | sort -u | tr \"\n\" ' '; echo" 115 | else 116 | alias users="users | tr ' ' \"\n\" | sort -u | tr \"\n\" ' '; echo" 117 | fi 118 | 119 | # Sun systems put software in an unusual spot (generally not on path) 120 | if [ `uname -r` == '5.11' ]; then 121 | export MANPATH="/usr/share/man:/opt/solstudio12.2/man" 122 | export PATH="$PATH:/opt/solstudio12.2/bin" 123 | else 124 | export MANPATH="/usr/share/man:/usr/sfw/man:/opt/sfw/man:/opt/SUNWspro/man:/usr/local/man" 125 | export PATH="$PATH:/usr/sfw/bin:/opt/sfw/bin" 126 | export PATH="$PATH:/opt/SUNWspro/bin:/opt/SUNWspro/prod/bin" 127 | fi 128 | 129 | export PATH="$PATH:/usr/sbin:/opt/csw/bin" 130 | ;; 131 | 132 | *) 133 | ;; 134 | esac 135 | 136 | # Host-specific settings 137 | # 138 | # Some hosts (i.e. Mac OSX) give us a fully qualified name - we don't want that 139 | 140 | S_HOSTNAME=`hostname` 141 | S_HOSTNAME=${S_HOSTNAME/\.opsmgr\.lan/} 142 | 143 | case $S_HOSTNAME in 144 | scxcore-rhel50-01 | scxcore-rhel51-01) 145 | export PATH=/usr/java/default/bin:$PATH 146 | ;; 147 | esac 148 | 149 | unset S_HOSTNAME 150 | 151 | # Some additional path stuff 152 | 153 | if [ -f /opt/git/bin/git ]; then 154 | export PATH=/opt/git/bin:${PATH} 155 | unset SSH_ASKPASS 156 | fi 157 | 158 | if [ -f ~/dev/git/myrepos/mr ]; then 159 | export PATH=~/dev/git/myrepos:$PATH 160 | fi 161 | 162 | # 163 | # Support for cmake 164 | # 165 | 166 | # First see if we have /opt/cmake; if so, that overrules all 167 | 168 | if [ -d /opt/cmake/bin ]; then 169 | export PATH=/opt/cmake/bin:$PATH 170 | fi 171 | 172 | # We may have cmake3, but not cmake; if so, set alias 173 | 174 | if type cmake3 > /dev/null 2> /dev/null; then 175 | alias cmake=cmake3 176 | fi 177 | 178 | # If ccache is installed, then add it to head of path 179 | # (easiest way for cmake to use it without command line options) 180 | 181 | if [ -d /usr/lib64/ccache ]; then 182 | export PATH="/usr/lib64/ccache:$PATH" 183 | fi 184 | 185 | # 186 | # Support for go (language) 187 | # 188 | 189 | if [ -d /usr/local/go ]; then 190 | export PATH=$PATH:/usr/local/go/bin 191 | 192 | export GOPATH=$HOME/go 193 | export PATH=$PATH:$GOPATH/bin 194 | fi 195 | 196 | # 197 | # Support for pyenv 198 | # 199 | 200 | if [ -d ~/.pyenv ]; then 201 | export PATH="/home/jeffcof/.pyenv/bin:$PATH" 202 | eval "$(pyenv init -)" 203 | eval "$(pyenv virtualenv-init -)" 204 | fi 205 | 206 | # Support for rbenv 207 | if [ -d ~/.rbenv ]; then 208 | export PATH="$HOME/.rbenv/bin:$PATH" 209 | eval "$(rbenv init -)" 210 | fi 211 | 212 | export PATH=.:~/bin:${PATH} 213 | 214 | # 215 | # Functions 216 | # 217 | 218 | # Function: global_find 219 | # 220 | # Search for a string globally throughout a directory structure 221 | # 222 | # Parameters: 223 | # String to search (Typically quoted) String to search for 224 | # Search Path Directory search path to begin searching at 225 | 226 | global_find_usage() 227 | { 228 | echo "Usage: global_find " 1>&2 229 | } 230 | 231 | global_find() 232 | { 233 | if [ -z "${1}" -o -z "${2}" ]; then 234 | global_find_usage 235 | return 1; 236 | fi 237 | 238 | echo "Starting search for string \"$1\" in file path \"$2\" ..." 239 | 240 | # Only Linux appears to have '-0' for xargs ... 241 | if [ $(uname -s) = "Linux" ]; then 242 | find $2 -type f -print0 | xargs -0 grep -i "$1" 243 | else 244 | find $2 -type f | xargs grep -i "$1" 245 | fi 246 | } 247 | -------------------------------------------------------------------------------- /dotfiles/bash_profile/bashrc: -------------------------------------------------------------------------------- 1 | # Sample .bashrc for SuSE Linux 2 | # Copyright (c) SuSE GmbH Nuernberg 3 | 4 | # There are 3 different types of shells in bash: the login shell, normal shell 5 | # and interactive shell. Login shells read ~/.profile and interactive shells 6 | # read ~/.bashrc; in our setup, /etc/profile sources ~/.bashrc - thus all 7 | # settings made here will also take effect in a login shell. 8 | # 9 | # NOTE: It is recommended to make language settings in ~/.profile rather than 10 | # here, since multilingual X sessions would not work properly if LANG is over- 11 | # ridden in every subshell. 12 | 13 | # Some applications read the EDITOR variable to determine your favourite text 14 | # editor. So uncomment the line below and enter the editor of your choice :-) 15 | #export EDITOR=/usr/bin/vim 16 | #export EDITOR=/usr/bin/mcedit 17 | 18 | # For some news readers it makes sense to specify the NEWSSERVER variable here 19 | #export NEWSSERVER=your.news.server 20 | 21 | # If you want to use a Palm device with Linux, uncomment the two lines below. 22 | # For some (older) Palm Pilots, you might need to set a lower baud rate 23 | # e.g. 57600 or 38400; lowest is 9600 (very slow!) 24 | # 25 | #export PILOTPORT=/dev/pilot 26 | #export PILOTRATE=115200 27 | 28 | test -s ~/.alias && . ~/.alias || true 29 | -------------------------------------------------------------------------------- /dotfiles/pbuild/pbuild: -------------------------------------------------------------------------------- 1 | # 2 | # Configuration file for pbuild. This file is normally stored in ~/.pbuild, 3 | # but can be customized with environment variable "PBUILD" (full path). 4 | # 5 | 6 | # 7 | # Default log file location 8 | # With no customization, you get: "~/" (expanded to your home directory) 9 | # 10 | # You can customize with lines like the following: 11 | # logdir: ~/pbuild_logs 12 | # logdir_prior: ~/pbuild_logs/prior 13 | # 14 | # If specified, logdir_prior forms a logfile directory that log files are 15 | # moved to prior to pbuild starting up. This allows you to save one level 16 | # of prior log files from pbuild. 17 | # 18 | # Be certain to create the logfile directory prior to running pbuild 19 | 20 | logdir: ~/pbuild_logs 21 | logdir_prior: ~/pbuild_logs/prior 22 | 23 | # 24 | # Default selector to build if unspecified on command line. 25 | # 26 | # NOTE: This line must appear before all host entries to be handled properly! 27 | # 28 | # You can customize with a line like the following: 29 | # select: om 30 | 31 | select: om 32 | 33 | # 34 | # Systems to exclude in the build: 35 | # With no customization, you get: "" 36 | # 37 | # You can customize with a line like the following: 38 | # exclude: sun_5.10_sparc,suse_9_32 39 | 40 | # 41 | # Settings that may be customized: 42 | # With no cusomization, you get: 43 | # "CheckValidity,Debug,DeleteLogfiles,NoDiagnoseErrors,NoLogfileRename,NoLogfileSelect,Progress,SummaryScreen" 44 | # 45 | # You can customize with a line like the following: 46 | # 47 | # settings: LogfileRename,NoSummaryScreen 48 | 49 | settings: NoDiagnoseErrors,NoCheckValidity,LogfileRename,NoSummaryScreen 50 | 51 | # 52 | # Per-project configuration options: 53 | # Keyword:Project:value 54 | # 55 | # Example: "configure_options : om : --enable-local-omi" 56 | # 57 | # Valid keywords: make_target, configure_options 58 | 59 | # 60 | # Test settings that may be customized: 61 | # Attributes are controlled with "test_attributes", 62 | # Test names are controlled with "test_names". 63 | # 64 | # With no customization, you get all tests (no restrictions) 65 | # 66 | # You can customize with a line like the following: 67 | # 68 | # test_attributes: -slow 69 | # test_names: atomic,condition 70 | 71 | # 72 | # This rest of the file contains lines with three pieces of information per 73 | # line (space separated): 74 | # Optional: "Host:" constant to specify that this is a host entry 75 | # Key (name for referring to the entry) 76 | # Host name (DNS name or IP address) 77 | # Directory path on host 78 | # Project (must specify selector to specify project) 79 | # Project must be one of: 80 | # om (for Operations Manager), 81 | # oms (for Operatations Management Suite), or 82 | # a host of others (see documentation) 83 | # Optional: Select specification (to match with command line and/or default) 84 | # If a select entry is specified, you MUST specify a selector to build with 85 | # This is useful if you build multiple projects. If you only build one 86 | # project, then you need not specify the select specification. 87 | 88 | # Operations Manager 89 | 90 | host: aix_6.1 osd16-aix61-01 ~/dev/bld-scxcore om 91 | host: aix_7.1 osd16-aix71-01 ~/dev/bld-scxcore om 92 | host: hp_v3_ia64 osdevia-hpux31-01 ~/dev/bld-scxcore om 93 | host: sun_5.10_sparc osdevsp-sol10-01 ~/dev/bld-scxcore om 94 | host: sun_5.10_x86 osd86-sol10-01 ~/dev/bld-scxcore om 95 | host: sun_5.11_sparc osdevsp-sol11-02 ~/dev/bld-scxcore om 96 | host: sun_5.11_x86 osd86-sol11-01 ~/dev/bld-scxcore om 97 | host: rhel_7.1_ppc osdppc-rh71-01 ~/dev/bld-scxcore om 98 | host: suse_10_32 osd-sls10-01 ~/dev/bld-scxcore om 99 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-scxcore om 100 | 101 | #host: centos_7_64_p jc64-cent7x-01 ~/dev/p-repos/bld-scxcore om 102 | 103 | # 104 | # Apache Project 105 | # 106 | 107 | host: suse_10_32 osd-sls10-01 ~/dev/bld-apache apache 108 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-apache apache 109 | 110 | 111 | # 112 | # Configuration Manager 113 | # 114 | 115 | host: aix_6.1 osd16-aix61-01 ~/dev/bld-scxcm cm 116 | host: aix_7.1 osd16-aix71-01 ~/dev/bld-scxcm cm 117 | host: hp_v3_ia64 osdevia-hpux31-01 ~/dev/bld-scxcm cm 118 | host: sun_5.10_sparc osdevsp-sol10-01 ~/dev/bld-scxcm cm 119 | host: sun_5.10_x86 osd86-sol10-01 ~/dev/bld-scxcm cm 120 | host: sun_5.11_sparc osdevsp-sol11-02 ~/dev/bld-scxcm cm 121 | host: sun_5.11_x86 osd86-sol11-01 ~/dev/bld-scxcm cm 122 | host: suse_10_32 osd-sls10-01 ~/dev/bld-scxcm cm 123 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-scxcm cm 124 | 125 | # 126 | # DSC Project 127 | # 128 | 129 | host: suse_10_32 osd-sls10-01 ~/dev/bld-dsc dsc 130 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-dsc dsc 131 | 132 | # 133 | # MySQL Project 134 | # 135 | 136 | host: suse_10_32 osd-sls10-01 ~/dev/bld-mysql mysql 137 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-mysql mysql 138 | 139 | # 140 | # OMS Project 141 | # 142 | 143 | host: cent_5_32 osd-ct5-01 ~/dev/bld-omsagent oms 144 | host: cent_5_64 osd64-ct5-01 ~/dev/bld-omsagent oms 145 | 146 | # 147 | # Docker Project 148 | # 149 | 150 | host: suse_10_64 osd64-ub14-01 ~/dev/bld-docker docker 151 | 152 | # 153 | # OMI Project 154 | # 155 | 156 | host: aix_6.1 osd16-aix61-01 ~/dev/bld-omi omi 157 | host: aix_7.1 osd16-aix71-01 ~/dev/bld-omi omi 158 | host: centos_5_32 osd-ct5-01 ~/dev/bld-omi omi 159 | host: centos_5_64 osd64-ct5-01 ~/dev/bld-omi omi 160 | host: centos_6_64 osd64-ct61-01 ~/dev/bld-omi omi 161 | host: centos_7_64 osd64-ct7-01 ~/dev/bld-omi omi 162 | #host: centos_7.3_64 osdev64-cent73-01 ~/dev/bld-omi omi 163 | #host: debian_5_32 osd-deb5-01 ~/dev/bld-omi omi 164 | #host: debian_5_64 osd64-deb5-01 ~/dev/bld-omi omi 165 | host: hp_v3_ia64 osdevia-hpux31-01 ~/dev/bld-omi omi 166 | host: mac_10.11 osd-mac1012-02 ~/dev/bld-omi omi 167 | host: redhat_5_32 osd-rh5-01 ~/dev/bld-omi omi 168 | #host: redhat_5_64 ostcdev64-rhel5-01 ~/dev/bld-omi omi 169 | host: redhat_6_32 osd-rh6-01 ~/dev/bld-omi omi 170 | #host: redhat_6_64 ostcdev64-rhel6-01 ~/dev/bld-omi omi 171 | host: redhat_7_64 osd64-rh7-01 ~/dev/bld-omi omi 172 | host: redhat_7.1_ppc osdppc-rh71-01 ~/dev/bld-omi omi 173 | host: sun_5.10_sparc osdevsp-sol10-01 ~/dev/bld-omi omi 174 | host: sun_5.10_x86 osd86-sol10-01 ~/dev/bld-omi omi 175 | host: sun_5.11_sparc osdevsp-sol11-02 ~/dev/bld-omi omi 176 | host: sun_5.11_x86 osd86-sol11-01 ~/dev/bld-omi omi 177 | host: suse_10_32 osd-sls10-01 ~/dev/bld-omi omi 178 | host: suse_10_64 osd64-sls10-01 ~/dev/bld-omi omi 179 | host: suse_11_32 osd-sls11-01 ~/dev/bld-omi omi 180 | host: suse_11_64 osd64-sls11-01 ~/dev/bld-omi omi 181 | #host: suse_12_64 dev64-sles12-01 ~/dev/bld-omi omi 182 | host: ubuntu_14_64 osd64-ub14-01 ~/dev/bld-omi omi 183 | host: ubuntu_16_64 osd64-ub16-01 ~/dev/bld-omi omi 184 | 185 | host: centos_7_64_p jc64-cent7x-01 ~/dev/p-repos/bld-omi omi 186 | 187 | # 188 | # PAL Project 189 | # 190 | 191 | host: centos_7_64_p jc64-cent7x-01 ~/dev/pal pal 192 | -------------------------------------------------------------------------------- /gitinstall-aix.md: -------------------------------------------------------------------------------- 1 | # Installing git on AIX 2 | 3 | Topics in this document: 4 | 5 | * [Problems with Common Repositories](#problems-with-common-repositories) 6 | * [Instructions for Installing git](#instructions-for-installing-git) 7 | 8 | ----- 9 | 10 | ##### Problems with Common Repositories 11 | 12 | Why did we not use common repositories to install git on AIX? 13 | 14 | File ```/usr/lib/libssl.a``` has binary references to the SSL library, 15 | libssl.so.0.9.8. When common repositories installed git, they 16 | installed a newer version of SSL with it (in /usr/local). 17 | 18 | This caused problems with Jenkins; Jenkins was unable to properly use 19 | git (via Java) because SSL 1.0.x wasn't referenced in 20 | ```/usr/lib/libssl.a```. By replacing the file with a newer one from 21 | the /usr/local directory, this caused OMI to link against SSL 1.0.x, 22 | would result in customers being unable to install OMI properly. 23 | 24 | 25 | ##### Instructions for Installing git 26 | 27 | The instructions to install git work properly on both AIX 6.1 and AIX 7.1: 28 | 29 | 1. Install RPM dependencies from [IBM](http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html) 30 | - autoconf 31 | - m4 32 | - zlib 33 | - zlib-devel 34 | 2. Extract git v2.7 source from [Github](https://github.com/git/git/releases/tag/v2.7.0) 35 | 3. Configure git 36 | - `cd git-2.7.0/; make configure; ./configure --without-tcltk` 37 | 4. Build and install 38 | - `sudo make install` 39 | -------------------------------------------------------------------------------- /gitinstall-hp.md: -------------------------------------------------------------------------------- 1 | # Installing git on HP-UX 2 | 3 | Topics in this document: 4 | 5 | * [Installing via Depot Packages](#installing-via-depot-packages) 6 | * [Installing via Internet](#installing-via-internet) 7 | * [Caching Depot Packages](#caching-depot-packages) 8 | * [Installing via Source Code](#installing-via-source-code) 9 | * [Basic git functionality test](#basic-git-functionality-test) 10 | 11 | ## Installing via Depot packages 12 | 13 | This is the recommended install method if you have read access to the wsscfs network share. 14 | 15 | * Login as root on the target HPv3 system : `ssh root@myHPv3system` 16 | * Create a temporary folder to hold the depot files : `mkdir -p /root/GIT` 17 | * Copy over the depot packages to `/root/GIT` 18 | * HPv3 ia64 : `\\redmond\wsscfs\OSTCData\NixArchive\SourceCodeManagement\git\HP-UX\v3ia64` 19 | * HPv3 parisc : `\\redmond\wsscfs\OSTCData\NixArchive\SourceCodeManagement\git\HP-UX\v3risc` 20 | * Unzip the compressed depot files : `gunzip /root/GIT/*.gz` 21 | * Install the git dependencies then git itself. The dependencies were [obtained using depothelper](#caching-depot-packages). 22 | 23 | For HPv3 ia64: 24 | ```shell 25 | swinstall -s /root/GIT/bzip2-1.0.6-ia64-11.31.depot bzip2 26 | swinstall -s /root/GIT/curl-7.46.0-ia64-11.31.depot curl 27 | swinstall -s /root/GIT/cyrus_sasl-2.1.26-ia64-11.31.depot cyrus_sasl 28 | swinstall -s /root/GIT/db-6.0.20-ia64-11.31.depot db 29 | # swinstall -s /root/GIT/depothelper-2.00-ia64-11.31.depot depothelper 30 | swinstall -s /root/GIT/editline-2.9-ia64-11.31.depot editline 31 | swinstall -s /root/GIT/expat-2.1.0-ia64-11.31.depot expat 32 | swinstall -s /root/GIT/flex-2.5.39-ia64-11.31.depot flex 33 | swinstall -s /root/GIT/fontconfig-2.11.1-ia64-11.31.depot fontconfig 34 | swinstall -s /root/GIT/freetype-2.6.2-ia64-11.31.depot freetype 35 | swinstall -s /root/GIT/gdbm-1.10-ia64-11.31.depot gdbm 36 | swinstall -s /root/GIT/gettext-0.19.7-ia64-11.31.depot gettext 37 | swinstall -s /root/GIT/heimdal-1.5.2-ia64-11.31.depot heimdal 38 | swinstall -s /root/GIT/libXft-2.3.2-ia64-11.31.depot libXft 39 | swinstall -s /root/GIT/libXrender-0.9.9-ia64-11.31.depot libXrender 40 | swinstall -s /root/GIT/libiconv-1.14-ia64-11.31.depot libiconv 41 | swinstall -s /root/GIT/libidn-1.32-ia64-11.31.depot libidn 42 | swinstall -s /root/GIT/libpng-1.6.8-ia64-11.31.depot libpng 43 | swinstall -s /root/GIT/m4-1.4.17-ia64-11.31.depot m4 44 | swinstall -s /root/GIT/openldap-2.4.43-ia64-11.31.depot openldap 45 | swinstall -s /root/GIT/openssl-1.0.2e-ia64-11.31.depot openssl 46 | swinstall -s /root/GIT/packages-ia64-11.31 packages 47 | swinstall -s /root/GIT/perl-5.10.1-ia64-11.31.depot perl 48 | swinstall -s /root/GIT/tcltk-8.5.18-ia64-11.31.depot tcltk 49 | swinstall -s /root/GIT/termcap-1.3.1-ia64-11.31.depot termcap 50 | swinstall -s /root/GIT/zlib-1.2.8-ia64-11.31.depot zlib 51 | 52 | swinstall -s /root/GIT/git-2.7.0-ia64-11.31.depot git 53 | ``` 54 | * [Test the installation](#basic-git-functionality-test) 55 | * Cleanup : `rm -rf /root/GIT` 56 | 57 | ## Installing via internet 58 | 59 | This method should be used if you don't already have access to the downloaded packages or if you want the latest versions of the packages installed. 60 | * Get the correct depothelper version for your flavor of HP from [hpux.connect.org](http://hpux.connect.org.uk/hppd/hpux/Sysadmin/depothelper-2.00/) 61 | * Install depothelper for example: `swinstall -s depothelper-2.00-hppa-11.31.depot depothelper` 62 | * Install git with depothelper : `/usr/local/bin/depothelper git` 63 | * [Test the installation](#basic-git-functionality-test) 64 | 65 | ### Caching Depot Packages 66 | To get a copy of the required depot packages required, depothelper can be run with these qualifiers: 67 | ``` 68 | depothelper -n -c /root/GIT git 69 | 70 | Options used: 71 | -n will download the depots but not install them. 72 | -c specifies the cache directory for downloaded files 73 | ``` 74 | 75 | ## Installing via Source Code 76 | 77 | It is possible that the git binary installed through depothelper does not work because the configuration of your system is different. Simply rebuild git from source. 78 | * Get the appropriate HP ported version of git source code from [hpux.connect.org](http://hpux.connect.org.uk/hppd/hpux/Development/Tools/git-2.7.0/). It is the one that has the package type : Source Code. 79 | * Although the file is named "tar.gz" it might just be a regular tar file. Verify with `file git-2.7.0-src-11.31.tar.gz` 80 | * Untar the git source `tar -x git-2.7.0-src-11.31.tar.gz` 81 | * Configure git for your system : `cd git-2.7.0/; ./configure` 82 | * Build git : `make` 83 | * Make sure an old version of git is not present : `sudo swremove git` 84 | * Install git : `sudo make install` 85 | * Test the installation by trying to clone a repo, create a commit in a new branch and push it upstream. 86 | * If the [basic functionality test](#basic-git-functionality-test) fails, you might have to reconfigure git using non default options. 87 | 88 | ## Basic git functionality test 89 | ```shell 90 | git clone --recursive git@github.com:Microsoft/Build-SCXcore.git 91 | cd Build-SCXcore/ 92 | git checkout -b test-branch 93 | echo test > test.txt 94 | git add test.txt 95 | git config --global user.email "you@example.com" 96 | git config --global user.name "Your Name" 97 | git config --global push.default current 98 | git commit -m "test message" 99 | git push 100 | git push origin --delete test-branch 101 | ``` 102 | -------------------------------------------------------------------------------- /gitinstall-linux.md: -------------------------------------------------------------------------------- 1 | # Installing git on Linux 2 | 3 | Installing git on Linux is very easy. Compared to the UNIX systems, 4 | installing git on Linux is a joy! :smiley: 5 | 6 | You basically have several choices: 7 | 8 | * If possible, install with the native package manager with a command 9 | like:
10 | ```yum install git``` (for RPM-based distributions), or
11 | ```apt-get install git``` (for DPKG-based distributions).
12 | Of course, if you install from the installation media, most Linux 13 | distributions include git there as well. 14 | * If that's not possible, install from source. [Download] 15 | (https://github.com/git/git/releases) the latest version and install 16 | with commands like: 17 | ``` 18 | make 19 | sudo make install 20 | ``` 21 | 22 | -------------------------------------------------------------------------------- /gitinstall-readme.md: -------------------------------------------------------------------------------- 1 | # Installing git 2 | 3 | * [Installing git on Linux systems](gitinstall-linux.md) 4 | * Installing git on UNIX systems 5 | * [AIX](gitinstall-aix.md) 6 | * [HP-UX](gitinstall-hp.md) 7 | * [Solaris](gitinstall-solaris.md) 8 | -------------------------------------------------------------------------------- /gitinstall-solaris.md: -------------------------------------------------------------------------------- 1 | # Installing git on Solaris 2 | 3 | We were able to use [common packages](https://www.opencsw.org/) 4 | to install git on Solaris. There are two mechanisms to install git: 5 | 6 | Topics in this document: 7 | 8 | * [Installing via Internet](#installing-via-internet) 9 | * [Installing via saved streams](#installing-via-saved-streams) 10 | 11 | ----- 12 | 13 | ##### Installing via Internet 14 | 15 | The process to install git is very simple. First, you need a program 16 | called pkgutil to deal with the .pkg files from [The OpenCSW Project] 17 | (https://www.opencsw.org/). The following command will both install 18 | the pkgutil package and then install git from the CSWgit package: 19 | 20 | ``` 21 | pkgadd -d http://get.opencsw.org/now 22 | /opt/csw/bin/pkgutil -U 23 | /opt/csw/bin/pkgutil -y -i git 24 | ``` 25 | 26 | To list the packages that were installed: 27 | 28 | ``` 29 | /usr/sbin/pkgchk -L CSWgit # list files 30 | ``` 31 | 32 | 33 | ##### Installing via Saved Streams 34 | 35 | [The OpenCSW Project]: https://www.opencsw.org/ 36 | [streams]: https://www.opencsw.org/manual/for-administrators/no-internet-access.html#no-internet-access 37 | 38 | [The OpenCSW Project][] allows *streams* to 39 | be downloaded locally, and for installation of git to happen from 40 | those streams. To guarentee that we can always install git, even if 41 | [The OpenCSW Project][] is no longer available, 42 | we have saved [streams][] to install git on Solaris. 43 | 44 | The file share that contains the Solaris files is: 45 | 46 | ``` 47 | \\redmond\wsscfs\OSTCData\NixArchive\SourceCodeManagement\git\Solaris 48 | ``` 49 | 50 | The following table describes the subdirectory for each of our supported 51 | Solaris platforms. Each location contains a stream file for the associated 52 | platform (called *git-and-others.pkg*), a command script to install it, and 53 | a download.log file showing the commands used to create the *stream* file 54 | (in case the stream file becomes corrupted): 55 | 56 | Version | Architecture | Directory | Command Script 57 | ------- | ------------ | --------- | -------------- 58 | 5.10 | sparc | 5.10/sparc | install_git_Solaris_5.10_sparc.sh 59 | 5.10 | x86 | 5.10/i386 | install_git_Solaris_5.10_i386.sh 60 | 5.11 | sparc | 5.11/sparc | install_git_Solaris_5.11_sparc.sh 61 | 5.11 | x86 | 5.11/i386 | install_git_Solaris_5.11_i386.sh 62 | 63 | To install git, download the package and the shell script to a directory. 64 | The follow command sequence shows the appropriate steps for installation: 65 | 66 | ``` 67 | cd 68 | sudo bash 69 | chmod +x 70 | ./ 71 | ``` 72 | -------------------------------------------------------------------------------- /images/MobAgent-Key-List.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/ostc-docs/1634b25856f49c94f60ba843a45a6657ef69571f/images/MobAgent-Key-List.jpg -------------------------------------------------------------------------------- /images/MobaXterm-Configuration.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/ostc-docs/1634b25856f49c94f60ba843a45a6657ef69571f/images/MobaXterm-Configuration.jpg -------------------------------------------------------------------------------- /images/macosx-AppStore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/ostc-docs/1634b25856f49c94f60ba843a45a6657ef69571f/images/macosx-AppStore.png -------------------------------------------------------------------------------- /msft-bin/addme: -------------------------------------------------------------------------------- 1 | #/bin/bash 2 | 3 | #set -x 4 | 5 | OS=`uname -s` 6 | mygid=7903 7 | myuid="556" 8 | myuname="jeffcof" 9 | mygrpname=scxdev 10 | 11 | while [ $# -ne 0 ]; do 12 | case "$1" in 13 | -uid ) 14 | myuid=$2 15 | shift 16 | ;; 17 | 18 | -uname ) 19 | myuname=$2 20 | shift 21 | ;; 22 | 23 | * ) 24 | echo "addme -uid -uname " 25 | exit 2 26 | ;; 27 | 28 | esac 29 | 30 | shift 31 | 32 | done 33 | 34 | myhome=/home/$myuname 35 | 36 | if [ "$myuid" = "" -o "$myuname" = "" ]; then 37 | echo "You need to modify the script with your information" 38 | echo "or supply the information on the command line..." 39 | exit 1 40 | fi 41 | 42 | # Override default for Solaris 43 | if [ "$OS" = "SunOS" ]; then 44 | myhome=/export/home/$myuname 45 | fi 46 | 47 | # Is my group already here? 48 | grep :${mygid}: /etc/group > /dev/null 49 | 50 | if [ $? -eq 0 ]; then 51 | echo "group already exists..." 52 | else 53 | if [ "$OS" = "AIX" ]; then 54 | mkgroup -A id=$mygid $mygrpname 55 | else 56 | groupadd -g $mygid $mygrpname 57 | fi 58 | fi 59 | 60 | # Check for my username 61 | pwdentrybyname=`grep $myuname /etc/passwd` 62 | 63 | if [ -n "$pwdentry" ]; then 64 | 65 | echo "Username already exists, checking uid." 66 | 67 | // Get the entry by UID... 68 | pwdentrybyuid=`grep $myuid /etc/passwd` 69 | 70 | if [ -z "$pwentrybyuid" ] && ["$pwdentrybyname" != "pwdentrybyuid" ]; then 71 | echo "uid already in use and it's not you..." 72 | exit 2 73 | fi 74 | fi 75 | 76 | 77 | case "$OS" in 78 | "SunOS"|"AIX" ) 79 | useradd -g $mygid -u $myuid -d $myhome -s /bin/bash $myuname 80 | usermod -G staff $myuname 81 | ;; 82 | 83 | * ) 84 | useradd -g $mygrpname -u $myuid -d $myhome -s /bin/bash $myuname 85 | usermod -G users $myuname 86 | ;; 87 | esac 88 | 89 | 90 | # SLES9 seems to ignore the create directory step, for some reason.. 91 | if [ ! -d $myhome ]; then 92 | mkdir $myhome 93 | if [ $? -ne 0 ]; then 94 | echo "Unable to create home directory..." 95 | exit 99 96 | fi 97 | fi 98 | 99 | 100 | 101 | chown $myuname $myhome 102 | chgrp $mygrpname $myhome 103 | chmod 755 $myhome 104 | 105 | passwd $myuname 106 | -------------------------------------------------------------------------------- /msft-bin/arch: -------------------------------------------------------------------------------- 1 | #/bin/bash 2 | 3 | #******************************************************** 4 | #* * 5 | #* Copyright (C) Microsoft. All rights reserved. * 6 | #* * 7 | #******************************************************** 8 | 9 | 10 | #Debugging Help 11 | #clear 12 | #set -x 13 | 14 | VERSION= 15 | PATCH= 16 | PLATFORM= 17 | ARCH= 18 | 19 | SuSE_Release="/etc/SuSE-release" 20 | SUSE_Release="/etc/SUSE-release" 21 | RH_Release="/etc/redhat-release" 22 | FED_Release="/etc/fedora-release" 23 | 24 | 25 | GetARCH() { 26 | 27 | case "$PLATFORM" in 28 | MacOS | Hpux) 29 | ARCH=`uname -m` 30 | ;; 31 | 32 | *) 33 | ARCH=`uname -p` 34 | ;; 35 | esac 36 | 37 | case $ARCH in 38 | 39 | x86_64 ) 40 | ARCH=x64 41 | ;; 42 | 43 | i386|i486|i586|i686 ) 44 | ARCH=x86; 45 | ;; 46 | 47 | 9000/*) 48 | ARCH=PA 49 | ;; 50 | 51 | ia64) 52 | ARCH=i64 53 | ;; 54 | 55 | ppc|ppc64|powerpc) 56 | ARCH=ppc 57 | ;; 58 | 59 | esac 60 | } 61 | 62 | 63 | GetLinuxInfo() { 64 | 65 | OSName=`/bin/egrep -o 'Red Hat Enterprise Linux ES|Red Hat Enterprise Linux|Red Hat Enterprise Linux Server|Red Hat Enterprise Client|Red Hat Enterprise Desktop|Fedora|CentOS|Ubuntu|SUSE Linux Enterprise Desktop|SUSE Linux Enterprise Server|SUSE LINUX Enterprise Server' $1` 66 | 67 | case $OSName in 68 | 69 | "Red Hat Enterprise Linux Client" | "Red Hat Linux Desktop" ) 70 | PLATFORM=RHED 71 | VERSION=`grep "$OSName" $1 | sed 's/[^0-9]*//g'` 72 | ;; 73 | 74 | "Red Hat Enterprise Linux Server" | "Red Hat Enterprise Linux ES" ) 75 | PLATFORM=RHEL 76 | if [ "$includePatchInfo" = "true" ]; then 77 | VERSION=`grep "$OSName" $1 | sed 's/[^0-9]*//g'` 78 | else 79 | VERSION=`grep "$OSName" $1 | sed 's/\..*$//;s/[^0-9]*//g'` 80 | fi 81 | ;; 82 | 83 | "SUSE Linux Enterprise Desktop" ) 84 | PLATFORM=SLED 85 | VERSION=`grep VERSION $1 | sed 's/[ \t]//g;s/.*=//'` 86 | if [ "$includePatchInfo" = "true" ]; then 87 | PATCH=`grep PATCH $1 | sed 's/[ \t]//g;s/.*=//'` 88 | fi 89 | ;; 90 | 91 | "SUSE LINUX Enterprise Server"|"SUSE Linux Enterprise Server") 92 | PLATFORM=SLES 93 | VERSION=`grep VERSION "$1" | sed 's/[ \t]//g;s/.*=//'` 94 | if [ "$includePatchInfo" = "true" ]; then 95 | PATCH=`grep PATCH $1 | sed 's/[ \t]//g;s/.*=//'` 96 | fi 97 | ;; 98 | 99 | "Fedora" ) 100 | PLATFORM=Fedora 101 | VERSION=`grep "$OSName" $1 | sed 's/[^0-9]*//g'` 102 | ;; 103 | 104 | "CentOS" ) 105 | PLATFORM=RHEL 106 | if [ "$includePatchInfo" = "true" ]; then 107 | VERSION=`grep "$OSName" $1 | sed 's/[^0-9]*//g'` 108 | else 109 | VERSION=`grep "$OSName" $1 | sed 's/\..*$//;s/[^0-9]*//g'` 110 | fi 111 | ;; 112 | 113 | "Ubuntu" ) 114 | PLATFORM=Ubuntu 115 | VERSION=`grep "$OSName" $1 | sed 's/[^0-9]*//g'` 116 | ;; 117 | 118 | * ) 119 | echo "Error Unrecognized Linux OS." 120 | ;; 121 | 122 | esac 123 | } 124 | 125 | 126 | 127 | # "Main" 128 | 129 | # Parse Command Line options. 130 | while getopts ":poh" opt; do 131 | case $opt in 132 | p ) 133 | includePatchInfo="true" 134 | ;; 135 | 136 | o ) 137 | osonly="true" 138 | ;; 139 | 140 | h ) 141 | echo "usage: arch [-p] [-o]" 142 | echo " -p Include patch level" 143 | echo " -o Display only OS & Version e.g RHEL5" 144 | exit 1 145 | esac 146 | done 147 | 148 | 149 | # Done Parsing options. 150 | 151 | case `uname -s` in 152 | 153 | Linux ) 154 | if [ -r $SuSE_Release ]; then 155 | GetLinuxInfo "$SuSE_Release" 156 | elif [ -r $SUSE_Release ]; then 157 | GetLinuxInfo "$SUSE_Release" 158 | elif [ -r $RH_Release ]; then 159 | GetLinuxInfo "$RH_Release" 160 | elif [ -r $FED_Release ]; then 161 | GetLinuxInfo "$FED_Release" 162 | fi 163 | ;; 164 | 165 | HP-UX ) 166 | VERSION=`uname -r` 167 | PLATFORM=Hpux 168 | ;; 169 | 170 | AIX ) 171 | VERSION=`oslevel | sed 's/\.//g;s/0//g'` 172 | PLATFORM=Aix 173 | ;; 174 | 175 | SunOS ) 176 | PLATFORM=Sol 177 | VERSION=`uname -r | sed 's/[0-9]\.//'` 178 | ;; 179 | 180 | Darwin ) 181 | PLATFORM=MacOS 182 | if [ "$includePatchInfo" = "true" ]; then 183 | VERSION=`sw_vers -productVersion | sed 's/[^0-9]*//g'` 184 | else 185 | VERSION=`sw_vers -productVersion | sed 's/\([0-9][0-9]\)\.\([0-9]\)\.\([0-9]\)/\1\2/;s/[^0-9]*//g'` 186 | fi 187 | 188 | ;; 189 | 190 | *) 191 | echo "Unknown" 192 | exit 0 193 | ;; 194 | 195 | esac 196 | 197 | GetARCH 198 | 199 | if [ "$osonly" = "true" ]; then 200 | echo ${PLATFORM}${VERSION}${PATCH} 201 | else 202 | echo ${PLATFORM}${VERSION}${PATCH}${ARCH} 203 | fi 204 | -------------------------------------------------------------------------------- /msft-bin/getkits.sh: -------------------------------------------------------------------------------- 1 | kitID=scx-1.0.5-49 2 | destDir=~/scx-kits 3 | 4 | hostlist="scxaix3-1 scxaix1 scxhpi10 scxhpr3 scxhpi1 scxhpr2 \ 5 | scxcr-mac104-03 scx-mac04 \ 6 | scxcrd-rhe40-01 scxom64-rhel40-03 \ 7 | scxcore-rhel50-01 scxom64-rhel52-03 \ 8 | scxnetra01 scxsun14 scxsun12 scxcore-solx86-01 \ 9 | scxsles9-03b scxom64-sles10-03" 10 | 11 | # Go fetch all the remote kits 12 | 13 | for i in $hostlist; do 14 | scp ${i}:dev/target/*_Debug/${kitID}.* ${destDir} 15 | done 16 | 17 | # Special case the local kit 18 | 19 | cp -v ~/dev/b/target/*_Debug/${kitID}.* ${destDir} 20 | 21 | exit 22 | -------------------------------------------------------------------------------- /msft-bin/installkits.sh: -------------------------------------------------------------------------------- 1 | kitID=scx-1.0.4-234 2 | sourceDir=~/scx-kits/BETA 3 | 4 | AIX_LIST="scxaix1" 5 | HP_LIST="scxhpr2" 6 | HP_PRIV_LIST="" 7 | LINUX_LIST="scxcore-rhel50-01 scxcore-suse01" 8 | LINUX_PRIV_LIST="" 9 | SUN_LIST="scxsun14 scxsun12" 10 | SUN_PRIV_LIST="" 11 | 12 | #AIX_LIST="scxaix3-1 scxaix1" 13 | #HP_LIST="scxhpr3 scxhpr2" 14 | #HP_PRIV_LIST="root@scxhpvm01 root@scxhpi3" 15 | #LINUX_LIST="scxrhel4-01 scxcore-rhel50-01 scxom64-rhel52-03 \ 16 | # scxsles9-01 scxcore-suse01 scxom64-sles10-03" 17 | #LINUX_PRIV_LIST="root@scxom64-rhel40-01" 18 | #SUN_LIST="scxsun14 scxsun12 scxcore-solx86-01" 19 | #SUN_PRIV_LIST="root@scxsun01-s8" 20 | 21 | for i in $AIX_LIST; do 22 | echo "Starting host $i ..." 23 | ssh $i sudo /usr/sbin/installp -u scx.rte 24 | read -p "Press return:" 25 | done 26 | 27 | for i in $HP_LIST; do 28 | echo "Starting host $i ..." 29 | ssh $i sudo /usr/sbin/swremove scx 30 | read -p "Press return:" 31 | done 32 | 33 | for i in $HP_PRIV_LIST; do 34 | echo "Starting host $i ..." 35 | ssh $i /usr/sbin/swremove scx 36 | read -p "Press return:" 37 | done 38 | 39 | for i in $LINUX_LIST; do 40 | echo "Starting host $i ..." 41 | ssh $i sudo /bin/rpm --erase scx 42 | read -p "Press return:" 43 | done 44 | 45 | for i in $LINUX_PRIV_LIST; do 46 | echo "Starting host $i ..." 47 | ssh $i /bin/rpm --erase scx 48 | read -p "Press return:" 49 | done 50 | 51 | for i in $SUN_LIST; do 52 | echo "Starting host $i ..." 53 | ssh $i /opt/sfw/bin/sudo /usr/sbin/pkgrm MSFTscx 54 | done 55 | 56 | for i in $SUN_PRIV_LIST; do 57 | echo "Starting host $i ..." 58 | ssh $i /usr/sbin/pkgrm MSFTscx 59 | done 60 | 61 | exit 62 | -------------------------------------------------------------------------------- /msft-bin/mount-builds.sh: -------------------------------------------------------------------------------- 1 | mount -t nfs -o ro,nolock wsscnafiler43.redmond.corp.microsoft.com:/OSTCData /mnt/ostcdata 2 | -------------------------------------------------------------------------------- /msft-bin/mount-ostcdata.sh: -------------------------------------------------------------------------------- 1 | sudo mount -o vers=3 wsscnafiler43.redmond.corp.microsoft.com:/OSTCNix /mnt/ostcdata 2 | -------------------------------------------------------------------------------- /msft-bin/removekits.sh: -------------------------------------------------------------------------------- 1 | AIX_LIST="scxaix1" 2 | HP_LIST="scxhpr2" 3 | HP_PRIV_LIST="" 4 | LINUX_LIST="scxcore-rhel50-01 scxcore-suse01" 5 | LINUX_PRIV_LIST="" 6 | SUN_LIST="scxnetra01 scxsun14 scxsun12" 7 | SUN_PRIV_LIST="" 8 | 9 | #AIX_LIST="scxaix3-1 scxaix1" 10 | #HP_LIST="scxhpr3 scxhpr2" 11 | #HP_PRIV_LIST="root@scxhpvm01 root@scxhpi3" 12 | #LINUX_LIST="scxrhel4-01 scxcore-rhel50-01 scxom64-rhel52-03 \ 13 | # scxsles9-01 scxcore-suse01 scxom64-sles10-03" 14 | #LINUX_PRIV_LIST="root@scxom64-rhel40-01" 15 | #SUN_LIST="scxsun14 scxsun12 scxcore-solx86-01" 16 | #SUN_PRIV_LIST="root@scxsun01-s8" 17 | 18 | for i in $AIX_LIST; do 19 | echo "Starting host $i ..." 20 | ssh $i sudo /usr/sbin/installp -u scx.rte 21 | read -p "Press return:" 22 | done 23 | 24 | for i in $HP_LIST; do 25 | echo "Starting host $i ..." 26 | ssh $i sudo /usr/sbin/swremove scx 27 | read -p "Press return:" 28 | done 29 | 30 | for i in $HP_PRIV_LIST; do 31 | echo "Starting host $i ..." 32 | ssh $i /usr/sbin/swremove scx 33 | read -p "Press return:" 34 | done 35 | 36 | for i in $LINUX_LIST; do 37 | echo "Starting host $i ..." 38 | ssh $i sudo /bin/rpm --erase scx 39 | read -p "Press return:" 40 | done 41 | 42 | for i in $LINUX_PRIV_LIST; do 43 | echo "Starting host $i ..." 44 | ssh $i /bin/rpm --erase scx 45 | read -p "Press return:" 46 | done 47 | 48 | for i in $SUN_LIST; do 49 | echo "Starting host $i ..." 50 | ssh $i /opt/sfw/bin/sudo /usr/sbin/pkgrm MSFTscx 51 | done 52 | 53 | for i in $SUN_PRIV_LIST; do 54 | echo "Starting host $i ..." 55 | ssh $i /usr/sbin/pkgrm MSFTscx 56 | done 57 | 58 | exit 59 | 60 | -------------------------------------------------------------------------------- /network-resources.md: -------------------------------------------------------------------------------- 1 | # OSTC Network Resources 2 | 3 | This page links to network resources that may be useful to those 4 | within the OSTC (Open Source Technology Center) group: 5 | 6 | Purpose | Network Resource 7 | ------- | ---------------- 8 | Jenkins Build Server | [http://jenkins-02.scx.com](http://jenkins-02.scx.com) 9 | Jenkins Build Share | `\\redmond\wsscfs\OSTCData\Builds` 10 | CDM Build Share (Legacy) | `\\cdmbuilds\Builds` 11 | OSTCData | `\\ostcnfs-01.redmond.corp.microsoft.com\ostcdata` 12 | OSTCNix | `\\redmond\wsscfs\OSTCNix` 13 | -------------------------------------------------------------------------------- /setup-MobaXterm.md: -------------------------------------------------------------------------------- 1 | # Configuring MobaXterm 2 | 3 | To configure the MobaXterm SSH client to use agent keys, do the following: 4 | 5 | - Edit the configuration in MobaXterm by selecting “Settings -> Configuration” 6 | - Select the SSH tab in the Configuration UI 7 | - Under the “SSH agents”, select the ‘Use interal SSH agent “MobAgent”’ 8 | 9 | ![Left](images/MobaXterm-Configuration.jpg) 10 | 11 | - Click on the ‘Show keys currently loaded in MobAgent’ 12 | - If this is the first time clicking on this, it will state that the MobAgentis not running and would you like to start it. Select yes. 13 | - Close the MobAgent Key List UI 14 | - Close the Configuration UI 15 | - You are required to restart MobaXterm at this point. 16 | - After MobaXterm restarts. Log back onto your Linux system and run the following command:
17 | ```ssh-add //.ssh/id_rsa``` 18 | - In MobaXterm, open the “Settings -> Configuration” UI again then click on 19 | the “Show keys currently loaded in MobAgent” 20 | 21 | ![Left](images/MobAgent-Key-List.jpg) 22 | -------------------------------------------------------------------------------- /setup-build.md: -------------------------------------------------------------------------------- 1 | # Setting Up a Machine for Build Purposes 2 | 3 | Many projects have specific requirements to building, and those 4 | requirements are generally documented with the project itself. 5 | However, there is a *common set* of requirements that most projects 6 | require. These are captured here. 7 | 8 | Table of Contents: 9 | 10 | * [sudo configuration](#sudoers-configuration) 11 | * Machine-specific Setup Requirements 12 | * [HP-UX openssl.pc files](#hp-ux-openssl-pkg-config-files) 13 | 14 | ----- 15 | 16 | #### Sudoers configuration 17 | 18 | Two changes should be made to your sudoers configuration for omsagent 19 | to build properly. We suggest using ```visudo``` program unless you 20 | are confident on how to change /etc/sudoers properly. 21 | 22 | 1. Configure sudoers to not require a TTY. 23 | 24 | Some platforms require a TTY be default, and this can be problematic for 25 | background builds. If you have a line like: 26 | 27 | ```Defaults requiretty``` 28 | 29 | then comment it out (like this): 30 | 31 | ```#Defaults requiretty``` 32 | 33 | 2. Configure your account to not require a password by adding the 34 | NOPASSWD: qualifier to the appropriate line that affects your 35 | account. After the correct changes are applied to /etc/sudoers, test 36 | under your personal account with the following sequence: 37 | 38 | ```shell 39 | sudo -k 40 | sudo ls 41 | ``` 42 | 43 | If there is no password prompt, then /etc/sudoers was correctly modified. 44 | 45 | ----- 46 | 47 | #### HP-UX openssl pkg-config files 48 | 49 | Many projects require linking against OpenSSL. For consistency, such 50 | projects often use [pkg-config](https://en.wikipedia.org/wiki/Pkg-config) 51 | to get include file and linkage library information. Unfortunately, on the 52 | HP-UX platform, these files are wrong, causing problems when programs are 53 | later installed on the destination system. 54 | 55 | A sample openssl.pc file (for HP-UX 11.23 ia64) looks like this: 56 | 57 | ``` 58 | prefix=/opt/openssl 59 | exec_prefix=${prefix} 60 | libdir=${exec_prefix}/lib/hpux32 61 | includedir=${prefix}/include 62 | 63 | Name: OpenSSL 64 | Description: Secure Sockets Layer and cryptography libraries and tools 65 | Version: 0.9.7l 66 | Requires: 67 | Libs: -L${libdir} -lssl -lcrypto -Wl,+s -ldl 68 | Cflags: -I${includedir} 69 | ``` 70 | 71 | Two changes were made: 72 | 73 | * The *libdir* line has appended ```/hpux32``` to actually properly refer 74 | to the library location. 75 | * The *Libs* line has ```-lz``` removed from the end. In reality, OpenSSL 76 | does not appear to require libz.sl or libz.so, and including that here can 77 | cause problems if the destination system does not have that library. 78 | 79 | These errors are consistent for HP-UX openssl.pc files. Changes must be 80 | made to four sets of OpenSSL libraries: 81 | 82 | Version | Architecture | File Path 83 | ------- | ------------ | --------- 84 | 11.23 | ia64 | /opt/openssl/lib/hpux32/pkgconfig/openssl.pc 85 | 11.23 | parisc | /opt/openssl/lib/hpux32/pkgconfig/openssl.pc 86 | 11.31 | ia64 | /opt/openssl/lib/pkgconfig/openssl.pc 87 | 11.31 | parisc | /opt/openssl/lib/pkgconfig/openssl.pc 88 | -------------------------------------------------------------------------------- /setup-builddeps.md: -------------------------------------------------------------------------------- 1 | # Build System Dependencies 2 | 3 | For cost efficiency purposes, most UNIX-based projects on GitHub will 4 | have minimum supported versions for platform support. This will allow 5 | the OSTC team to efficiently utilize new hardware to support our 6 | `build` and `development` systems. 7 | 8 | The following indicates minimum supported versions for the following 9 | platforms: 10 | 11 | - AIX (IBM) Systems 12 | - [AIX 6.1](#aix-61) 13 | - [AIX 7.1](#aix-71) 14 | - [HPUX 11.31 IA](#hpux-1131-ia) 15 | - Solaris Platforms 16 | - [Solaris 10 Sparc](#solaris-10-sparc) 17 | - [Solaris 10 x86](#solaris-10-x86) 18 | - [Solaris 11 Sparc](#solaris-11-sparc) 19 | - [Solaris 11 x86](#solaris-11-x86) 20 | - [SuSE Linux Enterprise Server](#suse-linux-enterprise-server) 21 | 22 | ----- 23 | 24 | ### AIX 6.1 25 | 26 | Component | Version 27 | --------- | ------- 28 | OS version | 6100-07-06-1241 29 | xlC.rte | 11.1.0.2 30 | OpenSSL/openssl.base | 0.9.8.1800 31 | 32 | ### AIX 7.1 33 | 34 | Component | Version 35 | --------- | ------- 36 | OS version | 7100-01-06-1241 37 | xlC.rte | 11.1.0.2 38 | OpenSSL/openssl.base | 0.9.8.1800 39 | 40 | ### HPUX 11.31 IA 41 | 42 | On HP-UX, PAM is part of the core operating system components. There 43 | are no other dependencies. 44 | 45 | Component | Version 46 | --------- | ------- 47 | HPUX11i-OE | B.11.31.1109 48 | OS-Core.MinimumRuntime.CORE-SHLIBS | B.11.31 49 | SysMgmtMin | B.11.31.1109 50 | SysMgmtMin.openssl | A.00.09.08q.003 51 | PAM | Part of Core O/S 52 | 53 | ### Solaris 10 Sparc 54 | 55 | Component | Version | Revision 56 | --------- | ------- | -------- 57 | Release | Oracle Solaris 10 1/13 | s10s_u11wos_24a SPARC 58 | SUNWlibC | 5.10 | REV-2004.12.22 59 | SUNWlibmsr | 5.10 | REV=2004.11.23 60 | SUNWcslr | 11.10.0 | REV=2005.01.21.15.53 61 | SUNWcsl | 11.10.0 | REV=2005.01.21.15.53 62 | SUNWcsr | 11.10.0 | REV=2005.01.21.15.53 63 | SUNWopenssl-libraries | 11.10.0 | REV=2005.01.21.15.53 64 | 65 | ### Solaris 10 x86 66 | 67 | Component | Version | Revision 68 | --------- | ------- | -------- 69 | Release | Oracle Solaris 10 9/10 | s10x_u9wos_14a X86 70 | SUNWlibC | 5.10 | REV=2004.12.20 71 | SUNWlibmsr | 5.10 | REV=2004.12.18 72 | SUNWcslr | 11.10.0 | REV=2005.01.21.16.34 73 | SUNWcsl | 11.10.0 | REV=2005.01.21.16.34 74 | SUNWcsr | 11.10.0 | REV=2005.01.21.16.34 75 | SUNWopenssl-libraries | 11.10.0 | REV=2005.01.21.16.34 76 | 77 | ### Solaris 11 Sparc 78 | 79 | Component | Version | Revision 80 | --------- | ------- | -------- 81 | Release | Oracle Solaris 11 11/11 SPARC 82 | SUNWlibC | 5.11 | REV=2011.04.11 83 | SUNWlibmsr | 5.11 | REV=2011.04.11 84 | SUNWcslr | 11.11 | REV=2009.11.11 85 | SUNWcsl | 11.11 | REV=2009.11.11 86 | SUNWcsr | 11.11 | REV=2009.11.11 87 | SUNWopenssl-libraries | 11.11.0 | REV=2010.05.25.01.00 88 | 89 | ### Solaris 11 x86 90 | 91 | Component | Version | Revision 92 | --------- | ------- | -------- 93 | Release | Oracle Solaris 11 11/11 X86 94 | SUNWlibC | 5.11 | REV=2011.04.11 95 | SUNWlibmsr | 5.11 | REV=2011.04.11 96 | SUNWcslr | 11.11 | REV=2009.11.11 97 | SUNWcsl | 11.11 | REV=2009.11.11 98 | SUNWcsr | 11.11 | REV=2009.11.11 99 | SUNWopenssl-libraries | 11.11.0 | REV=2010.05.25.01.00 100 | 101 | ### SuSE Linux Enterprise Server 102 | 103 | Note that SuSE Linux 10 (SP1) for both i586 and x86_64 are used as 104 | universal build systems for all other Linux platforms. 105 | 106 | Required Package | Description | Minimum Version 107 | ---------------- | ----------- | --------------- 108 | glibc-2.4-31.30 | C Standard shared library | 2.4-31.30 109 | OpenSSL | OpenSSL Libraries; Secure Network Communications Protocol | 0.9.8a-18.15 110 | PAM | Pluggable Authentication Modules | 0.99.6.3-28.8 111 | -------------------------------------------------------------------------------- /setup-buildhosts.md: -------------------------------------------------------------------------------- 1 | # OSTC Build Hosts 2 | 3 | Note that it is nearly impossible to keep a completely accurate list of 4 | build hosts here. But hey, it's a stab. 5 | 6 | This list was generated by removing hosts from the [Jenkins Build Server] 7 | (http://jenkins-02.scx.com) that will never be used by Jenkins, primarily 8 | because the hosts are for legacy purposes (TFS projects, like OM 2012R2_UR), 9 | and then adding what is actually used by Jenkins for current purposes. There 10 | are, without a doubt, other build servers. 11 | 12 | Note that Jenkins keeps a build history for each host. To see this, select 13 | the host in question and click "Build History". 14 | 15 | An [alternate list](http://scxomt-ws8-07.scx.com/index.php), 16 | without the "Purpose" field, may be useful to you as well. 17 | 18 | ----- 19 | 20 | * Linux Build Systems 21 | * [CentOS Systems](#centos-build-systems) 22 | * [RedHat Systems](#redhat-build-systems) 23 | * [SuSE Build Systems](#suse-build-systems) 24 | * [Debian Build Systems](#debian-build-systems) 25 | * UNIX Build Systems 26 | * [AIX Systems](#aix-systems) 27 | * [HP-UX Systems](#hp-ux-systems) 28 | * [Solaris Systems](#solaris-systems) 29 | 30 | ----- 31 | 32 | ##### CentOS Build Systems 33 | 34 | Version | Architecture | Host Name | Purpose 35 | ------- | ------------ | --------- | ------- 36 | 5.0 | x86 | osbld-cent5-01 | Jenkins (OMS-Agent only) 37 | 5.0 | x86_64 | osbld64-cent5-01 | Jenkins (OMS-Agent only) 38 | 39 | 40 | ##### RedHat Build Systems 41 | 42 | Version | Architecture | Host Name | Purpose 43 | ------- | ------------ | --------- | ------- 44 | 4.0 | x86 | osbld-rhel4-01 | Legacy 45 | 4.0 | x86_64 | osbld64-rh40-01 | Legacy 46 | 5.0 | x86 | osbld-rhe5-01 | Legacy 47 | 5.0 | x86_64 | osbld64-rhel5-01 | Legacy 48 | 6.0 | x86 | osbld-rhel6-01 | Legacy 49 | 6.0 | x86_64 | osbld64-rhel6-01 | Legacy 50 | 7.0 | x86_64 | osbld64-rhel7-01 | Legacy 51 | 52 | 53 | ##### SuSE Build Systems 54 | 55 | Version | Architecture | Host Name | Purpose 56 | ------- | ------------ | --------- | ------- 57 | 9.0 | x86 | osbld-sle9-01 | Legacy 58 | 10.0 | x86 | osbld-sles10-01 | Jenkins, Universal Build System 59 | 10.0 | x86 | osvmb-sles10-01 | Legacy, VMM Build System 60 | 10.0 | x86_64 | osbld64-sles10-01 | Jenkins, Universal Build System 61 | 10.0 | x86_64 | osvmb64-sles10-01 | Legacy, VMM Build System 62 | 11.0 | x86 | osbld-sles11-01 | Legacy 63 | 11.0 | x86_64 | osbld64-sle11-01 | Legacy 64 | 12.0 | x86_64 | osbld64-sles12-01 | Legacy 65 | 66 | 67 | ##### Debian Build Systems 68 | 69 | Version | Architecture | Host Name | Purpose 70 | ------- | ------------ | --------- | ------- 71 | 5.0 | x86 | osbld-deb5-01 | Legacy 72 | 5.0 | x86_64 | osbld64-deb5-01 | Legacy 73 | 74 | 75 | ##### AIX Systems 76 | 77 | Version | Architecture | Host Name | Purpose 78 | ------- | ------------ | --------- | ------- 79 | 5.3 | ppc | osbld-aix53-01 | Legacy 80 | 6.1 | ppc | osbld-aix61-01 | Legacy 81 | 6.1 | ppc | osbld16-aix61-01 | Jenkins 82 | 7.1 | ppc | osbld-aix71-01 | Legacy 83 | 7.1 | ppc | osbld16-aix71-01 | Jenkins 84 | 85 | 86 | ##### HP-UX Systems 87 | 88 | Version | Architecture | Host Name | Purpose 89 | ------- | ------------ | --------- | ------- 90 | 11.23 | ia64 | osbldia-hpux23-01 | Legacy 91 | 11.23 | pa-risc | osbldpa-hpux23-01 | Legacy 92 | 11.31 | ia64 | osbldia-hpux31-01 | Jenkins 93 | 11.31 | pa-risc | osbldpa-hpux31-01 | Legacy 94 | 95 | 96 | ##### Solaris Systems 97 | 98 | Version | Architecture | Host Name | Purpose 99 | ------- | ------------ | --------- | ------- 100 | 9.0 | sparc | osbldsp-sol9-01 | Legacy 101 | 10.0 | x86 | osbld86-sol11-01 | Jenkins 102 | 10.0 | sparc | osbldsp-sol10-01 | Jenkins 103 | 11.0 | x86 | osbld86-sol11-01 | Jenkins 104 | 11.0 | sparc | osbldsp-sol11-01 | Jenkins 105 | -------------------------------------------------------------------------------- /setup-git.md: -------------------------------------------------------------------------------- 1 | # Setting up your environment for use with git 2 | 3 | We recommend following some basic steps to use git effectively: 4 | 5 | 1. [Set up authentication](#setting-up-authentication) with GitHub 6 | 2. [Configure git](#configuring-git) 7 | 8 | ----- 9 | 10 | #### Setting up authentication 11 | 12 | Authentication with GitHub can be a hassle unless you set up an SSH 13 | key via your github account. We would **strongly** suggest setting up an 14 | SSH key with a **strong passphrase**, adding the public key to your 15 | github account, and then add the private key to your SSH program to 16 | act as an SSH agent. 17 | 18 | The basic steps are: 19 | 20 | [Putty]: http://www.chiark.greenend.org.uk/~sgtatham/putty/ 21 | [Using Pageant]: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter9.html 22 | [SecureCRT]: https://www.vandyke.com/products/securecrt/index.html 23 | [SecureFX]: https://www.vandyke.com/products/securefx/index.html 24 | [Configure SecureCRT]: https://www.vandyke.com/support/tips/agent_forwarding.html#agent 25 | [MobaXterm]: http://mobaxterm.mobatek.net/ 26 | [Configure MobaXterm]: setup-MobaXterm.md 27 | [SSH Agent]: http://sshkeychain.sourceforge.net/mirrors/SSH-with-Keys-HOWTO/SSH-with-Keys-HOWTO-6.html 28 | [OpenSSH]: https://en.wikipedia.org/wiki/OpenSSH 29 | 30 | 1. [Create an SSH key for github](https://help.github.com/articles/generating-ssh-keys/) 31 | 2. Configure your SSH program to act as an SSH agent. Our team uses a 32 | variety of SSH programs. Some examples are: 33 | 1. [Putty][], [Using Pageant][] 34 | 2. [SecureCRT][]/[SecureFX][] bundle, [Configure SecureCRT][] 35 | 3. [MobaXterm][], [Configure MobaXterm][] 36 | 37 | Other SSH programs exist as well, or you can use the [SSH Agent][] 38 | that is included as part of [OpenSSH][] 39 | as well (although this only works for a single Linux session). 40 | 41 | The end result of this mechanism: You specify the passphrase once when 42 | you start your SSH program or agent, and then you never type the 43 | passphrase again. 44 | 45 | 46 | #### Configuring git 47 | 48 | Based on our workflow, we suggest that git is configured in specific 49 | ways to facilitate the way that we use the software. 50 | 51 | The mandatory settings (below) **must** be set for git to even 52 | function properly. 53 | 54 | The strongly suggested settings should generally be taken verbatim 55 | unless you have specific strong reasons for deviating, and you know 56 | what you're doing. 57 | 58 | The preference settings are useful to many, although your milage may 59 | vary. 60 | 61 | Finally, in common workflows with git, the aliases may make your work 62 | with git faster and easier. 63 | 64 | * Mandatory settings (**replace name/email with your own**): 65 | ``` 66 | git config --global user.name "First Last" 67 | git config --global user.email alias@microsoft.com 68 | 69 | git config --global pull.ff only 70 | git config --global push.default current 71 | ``` 72 | 73 | * Strongly suggested settings: 74 | ``` 75 | git config --global am.threeWay true 76 | git config --global apply.ignoreWhitespace change 77 | git config --global core.excludesfile ~/.gitignore 78 | git config --global log.decorate short 79 | git config --global rerere.enabled true 80 | git config --global rerere.autoUpdate true 81 | ``` 82 | 83 | * Preference Settings: 84 | ``` 85 | git config --global color.ui true 86 | git config --global core.editor "emacs -nw" 87 | git config --global credential.helper store 88 | git config --global help.autoCorrect -1 89 | git config --global log.abbrevCommit true 90 | git config --global log.date local 91 | git config --global url."git@github.com:".insteadOf "https://github.com/" 92 | ``` 93 | 94 | * Useful Aliases: 95 | ``` 96 | git config --global alias.co-master '!git checkout master && git submodule foreach git checkout master' 97 | git config --global alias.lol 'log --oneline --graph' 98 | git config --global alias.nuke '!git clean -fdx && git submodule foreach git clean -fdx' 99 | git config --global alias.sub-status '!git submodule foreach git status' 100 | git config --global alias.sync-subs '!git pull && git remote prune origin && git submodule foreach git pull && git submodule foreach git remote prune origin' 101 | git config --global alias.rmrbranch 'push origin --delete' # supplied by user 102 | git config --global alias.rmrprune 'remote prune origin' 103 | ``` 104 | -------------------------------------------------------------------------------- /setup-macosx.md: -------------------------------------------------------------------------------- 1 | # Setting up Mac OS/X Systems 2 | 3 | For Mac OS/X development, we use a high power Macintosh system 4 | (currently Mac Pro), set up as an infrastructure system, to run a 5 | number of different virtual machines (for build, development, or test 6 | purposes). 7 | 8 | For virtualization, we are using VMware Fusion, native on Mac OS/X. 9 | 10 | Note that, with only a few exceptions, Mac OS/X infrastructure hosts 11 | and Mac OS/X build/development hosts are set up identically. The 12 | instructions below will call out the differences to minimize 13 | maintenance to these instructions. 14 | 15 | ----- 16 | 17 | * [Setup Instructions](#setup-instructions) 18 | * [Default Account](#default-account) 19 | * [System Updates](#system-updates) 20 | * [Set Up sudoers File](#set-up-sudoers-file) 21 | * [System Preferences](#system-preferences) 22 | * [Enable root Account](#enable-root-account) 23 | * [Set Up hostname](#set-up-hostname) 24 | * [Install Development Tools](#install-development-tools) 25 | * [Install updatedns](#install-updatedns) 26 | * [Install Homebrew](#install-homebrew) 27 | * [Install Homebrew Packages](#install-homebrew-packages) 28 | * [Codesign GDB](#codesign-gdb) 29 | * [Increase Screen Resolution](#increase-screen-resolution) 30 | * [Creating a New Virtual Machine](#creating-a-new-virtual-machine) 31 | 32 | ----- 33 | 34 | ### Setup Instructions 35 | 36 | #### Default Account 37 | 38 | In general, the default account username is *admin* (full name: 39 | *Administrative Account*). It is easiest to set this up during 40 | Operating System installation, although if you set up some alternate 41 | account, you can create the *admin* account later. 42 | 43 | In particular, we do not use the *serviceb* account on either 44 | infrastructure systems nor development systems. Build systems do 45 | use *serviceb*. 46 | 47 | User accounts (be it for an end-user, or the serviceb account) should 48 | NOT have "Allow user to administer this computer" enabled on the 49 | *System Preferences/Users & Groups* dialog. Instead, they should use 50 | the sudo mechanism for sudo access as needed. 51 | 52 | #### System Updates 53 | 54 | Install all updates available from the *App Store* application 55 | (available under the Apple menu from the menu bar). Note that Jeff 56 | Coffler has created an iTunes account tied to his E-mail 57 | (jeffcof@microsoft.com). Contact him for the password if needed. 58 | 59 | After all updates are installed, navigate to *System Preferences/App 60 | Store* and, for "Free Downloads:", select Save Password. Here is a 61 | dialog to set everything properly: 62 | 63 | ![Left](images/macosx-AppStore.png) 64 | 65 | These settings will automatically apply updates, and will not require 66 | the iTunes password for each update. 67 | 68 | #### Set Up sudoers File 69 | 70 | After the commented out %wheel line, add a new line for %staff as follows: 71 | 72 | ``` 73 | ## Same thing without a password 74 | # %wheel ALL=(ALL) NOPASSWD: ALL 75 | %staff ALL=(ALL) NOPASSWD: ALL 76 | ``` 77 | 78 | #### System Preferences 79 | 80 | The follow table indicates the settings that must be changed in the 81 | System Preferences screens: 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 100 | 101 | 102 | 103 | 104 | 112 | 113 | 114 | 115 | 116 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 137 | 138 |
ComponentSetting
Desktop & Screen SaverSelect Message screen saver so, if screen saver is activated, 93 | it won't eat lots of CPU time to display fancy graphics. 94 |

95 | For infrastructure system: In Screen Saver tab, select Start after: Never in pulldown. This avoids screen saver from wasting CPU time for VMs. 96 |

97 | For virtual machines, execute the following command:
98 | sudo defaults write /Library/Preferences/com.apple.screensaver loginWindowIdleTime 0 99 |
Energy Saver 105 |
    106 |
  • If you have a slider for Computer sleep:, set it to never
    • 107 |
  • Check: Prevent computer from sleeping automatically
    • 108 |
  • Check: Wake for network access
    • 109 |
  • Check: Start up automatically after a power failure
    • 110 |
111 |
SharingName system appropriately (i.e. ostcdev-mac1011-01). 117 |

118 | Select: 119 |
    120 |
  • Screen Sharing (with VNC configured in Computer Settings...)
    • 121 |
  • Remote Login 122 |
123 |
NetworkConfigure the active network interface with DHCP.
App StoreCheck Automatically check for updates for all types of updates. 134 |

135 | Do NOT check Automatically download apps purchased on other Macs. 136 |
139 | 140 | #### Enable root Account 141 | 142 | This step is **NOT** needed on the infrastructure system, nor on build 143 | servers. This is only needed on Developer and Test systems. 144 | 145 | To enable the root account: 146 | 147 | 1. Navigate to *System Preferences / Users & Groups / Login Options*, 148 | 2. Select "Join..." at bottom right, 149 | 3. Open directory utility, 150 | 4. Unlock directory utility, 151 | 5. From menu bar for Directory Utility, select *Edit* -> *Enable root user* 152 | 153 | #### Set Up hostname 154 | 155 | To set up the hostname for the system, launch a command terminal and type: 156 | 157 | ``` 158 | sudo scutil --set HostName 159 | ``` 160 | 161 | where `` is the name of your host. Do not append scx.com to 162 | the hostname. 163 | 164 | #### Install Development Tools 165 | 166 | There are two choices for development tools: `command line tools` and 167 | `Xcode`. Because `Xcode` is quite large, we only recommend it if needed. 168 | 169 | Command line tools are sufficent for 'git' (and thus updatedns), as 170 | well as actually building/linking our products. Thus, we recommend the 171 | following tools to be installed based on system type: 172 | 173 | System Type | Development Tools 174 | ----------- | ----------------- 175 | Infrastructure | Command line tools 176 | Build System | Command line tools 177 | Development System | Xcode 178 | Test System | Command line tools 179 | 180 | To install `command line tools`, just invoke `git` from the command 181 | line (from a GUI connection to the Mac). If the tools are not 182 | present, you'll be prompted what to install. 183 | 184 | Note that `Xcode` is quite large, and will take several minutes to 185 | install. The lldb debugger only ships with `Xcode`, not the command 186 | line tools. 187 | 188 | #### Install updatedns 189 | 190 | This step differs slightly based on the type of system. See 191 | [Install Development Tools](#install-development-tools) 192 | for guidance on what should be installed prior to installing updatedns. 193 | 194 | * Launch a command terminal, and type: 195 | 196 | ``` 197 | git clone https://github.com/jeffaco/msft-updatedns.git updatedns 198 | ``` 199 | 200 | Once msft-updatedns is downloaded, issue the following commands: 201 | 202 | ``` 203 | cd updatedns 204 | ./updatedns.sh --configure -v 205 | ``` 206 | 207 | At this point, updatedns should run automatically and fix the DNS 208 | resolvers to use the SCX domain servers. 209 | 210 | #### Install Homebrew 211 | 212 | [Homebrew][] is "the missing package manager for macOS." 213 | 214 | Follow the installation instructions from [Homebrew][]. 215 | The short of it is reproduced here: 216 | 217 | ```sh 218 | /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 219 | ``` 220 | 221 | Next, fix the `/usr/local` directory (used by [Homebrew][]) permissions to be writable by the `staff` group: 222 | > This is needed because Homebrew (and macOS systems in general) tend to expect single users, not groups. 223 | 224 | ```sh 225 | sudo chgrp -R staff /usr/local 226 | sudo chmod -R g+w /usr/local 227 | ``` 228 | 229 | [homebrew]: http://brew.sh/ 230 | 231 | #### Install Homebrew Packages 232 | 233 | Once [Homebrew][] is installed, several [Homebrew][] packages must be 234 | installed as well. This can be done with the following command: 235 | 236 | ``` 237 | brew install pkg-config cmake openssl 238 | ``` 239 | 240 | #### Codesign GDB 241 | 242 | If practical, it would be better to use the debugger which is provided by 243 | Xcode for debugging purposes. That debugger is much more capable and reliable 244 | than gdb on the mac. Developers used to using the gdb debugger can find a 245 | document with translations between gdb and lldb commands 246 | [here](http://llvm.org/svn/llvm-project/lldb/tags/lldb-168/www/lldb-gdb.html). 247 | 248 | If you must use gdb, per the Homebrew installation notes, "gdb" requires special privileges 249 | to access machine ports. You will need to codesign the binary. For 250 | instructions, see: 251 | [BuildingOnDarwin](https://sourceware.org/gdb/wiki/BuildingOnDarwin). 252 | 253 | Since our macOS systems are shared, please check if a GDB certificate 254 | has already been created. 255 | 256 | Codesigning GDB needs to be done each time GDB updates, XCode updates, 257 | or the certificate expires. 258 | 259 | #### Increase Screen Resolution 260 | 261 | The video resolution of Mac Virtual Machines are rather limited to 262 | conserve overall resources in a heavily hosted environment. In rare 263 | situtions (when developers must connect using VNC to the Mac routinely), 264 | it may be necessary to increase the screen resolution of a virutal 265 | machine. 266 | 267 | When this is necessary, both administrative changes and user changes 268 | must be made to the virtual machine. 269 | 270 | ##### Increase Screen Resolution: Administrative Changes 271 | 272 | [VMware KB Article 1003][] discusses how to increase the screen 273 | resolution for all of their products. For VMware Fusion, the steps 274 | are roughly as follows: 275 | 276 | 1. Install VMware Tools on the virtual machine, 277 | 2. Power off the virtual machine, 278 | 3. Open the .vmx file on the host system (the system running VMware 279 | server) in a text editor for the virtual machine in question (expand 280 | shell bundle of the virtual machine to see this).

281 | Add a line to the file as follows: `svga.autodetect = TRUE` 282 |

283 | This file is generally located in the Documents folder for the 284 | administrative user, but this can be stored elsewhere if desired, 285 | 4. Save the file, 286 | 5. Restart the virtual machine. 287 | 288 | If you need extreme screen resolution (unlikely), refer to 289 | [VMware KB Article 1003]. 290 | 291 | [VMware KB Article 1003]: https://kb.vmware.com/kb/1003 292 | 293 | ##### Increase Screen Resolution: User Changes 294 | 295 | Once the administrative changes has been completed and the virtual 296 | machine has been rebooted, then the user of the virutal machine must 297 | inform the VMware Tools package of the desired resolution. 298 | 299 | This must be done via the command line on the virtual machine. The 300 | user should SSH to the host in question (or execute the command in 301 | a terminal window on the virutal machine) and enter a command like: 302 | 303 | ``` 304 | cd /Library/Application\ Support/VMware\ Tools 305 | ./vmware-resolutionSet 1920 1080 306 | ``` 307 | 308 | where `1920` is the requested width and `1080` is the requested 309 | height. Any width and height may be requested. 310 | 311 | Beware that many VNC clients will resize or scale the window based 312 | on the VNC client physical window size. Be certain that your VNC 313 | client is not configured to do this, or that the display window of 314 | the VNC client is large enough to accomodate your requested resolution. 315 | 316 | ### Creating a New Virtual Machine 317 | 318 | To create a new VM in VMware fusion, you must first download the 319 | operating system that you wish to use (i.e. El Capitan) from the App 320 | Store. Once downloaded, it is automatically placed in the 321 | */Applications/* folder, and you need to move it to make sure it won't 322 | get installed on system reboots. Move it into the administrator's 323 | desktop folder with a terminal by executing a command like: 324 | 325 | ``` 326 | mv /Applications/Install\ OS\ X\ El\ Capitan.app ~/Desktop 327 | ``` 328 | 329 | Once the operating to install is placed at the desktop: 330 | 331 | * Launch VMware Fusion. This can be done via the Applications folder 332 | via the finder, or by clicking magnifying glass on menu bar and typing 333 | "VMware" in the spotlight window and hitting return. Note that if 334 | VMware Fusion is already running (normally the case for virtual 335 | machines to be running), select *Window / Virtual Machine Library* 336 | from the menu bar once VMware Fusion is selected, 337 | * Select *Add* (+v) from the upper left of the window, 338 | * Drag *Install OS X El Capitan* from your desktop to the "Install 339 | from disk or image" section of the "Select the installation Method" 340 | window, 341 | * Click "Continue" from the "Create a New Virtual Machine" confirmation 342 | window. 343 | 344 | At this point, follow the standard instructions to configure the 345 | virtual machine from the top of this document. 346 | 347 | Suggested hard drive sizes for virtual machines: 348 | 349 | Machine Type | Size 350 | ------------ | ---- 351 | Build System | 24GB 352 | Development System | 64GB 353 | Test System | 16GB 354 | 355 | Note that if you must extend the disk size via VMware, then Mac OS/X 356 | won't see the additional space automatically. Boot the guest VM and 357 | issue the command (from a terminal window): 358 | 359 | ``` 360 | sudo diskutil resizeVolume / R 361 | ``` 362 | 363 | This will reformat the file system to recognize and use the additional 364 | disk space. 365 | -------------------------------------------------------------------------------- /setup-pbuild.md: -------------------------------------------------------------------------------- 1 | # Setting up for PBUILD 2 | 3 | [pbuild]: https://github.com/Microsoft/pbuild 4 | [OMI]: https://github.com/Microsoft/omi 5 | [OSTC Documentation]: https://github.com/Microsoft/ostc-docs 6 | [build systems]: https://github.com/Microsoft/ostc-tools/tree/master/build 7 | [Jeff Coffler's dotfiles repository]: dotfiles/pbuild/pbuild 8 | [Jeff Coffler's addme script]: msft-bin/addme 9 | [VNC Viewer]: https://www.realvnc.com/download/viewer/ 10 | 11 | [pbuild][] is a tool used as part of our development process to 12 | verify that the proposed code changes do not impact regression 13 | tests. Running [pbuild][] a mandatory step in the development 14 | process, and must be done before changes are submitted for review. 15 | 16 | ### Assumptions 17 | 18 | Pbuild is a generic test tool that can be used across a variety of 19 | projects. 20 | 21 | Users are assumed to be familiar with Git, Github and general OSTC 22 | development practices. For additional information, refer to other 23 | pages in [OSTC Documentation][]. 24 | 25 | ### Set up your [pbuild][] environment 26 | 27 | 1. Clone a copy of [pbuild][] on your primary development machine, 28 | 2. Get a sample .pbuild file from [Jeff Coffler's dotfiles repository][]. 29 | 3. Place the .pbuild file in your home directory, and edit the section 30 | relevant to your project according to your needs. Note that lines that 31 | start with `#` are ignored by pbuild. Fields in this file are explained 32 | in the header section of .pbuild file. 33 | 4. Create the log files directories for pbuild: 34 | 35 | ``` 36 | mkdir ~/pbuild_logs ~/pbuild_logs/prior 37 | ``` 38 | 39 | ### Set up base user files 40 | 41 | For remote build machines to work properly with [pbuild][], you must 42 | create `.bash_profile`, `.bashrc`, and SSH key files. 43 | 44 | If you don't already have `.bash_profile` and `.bashrc`, you can grab 45 | the ones used by the [build systems][]. These can 46 | be used as a starting point for you to customize your own files to set 47 | up your environment however you would like. 48 | 49 | **Note that our build processes require certain settings in your bash 50 | environment.** We suggest starting with the ones from the [build 51 | systems][] and, if you have existing bash environment files you wish 52 | to use, incorporate those settings into yours. 53 | 54 | Create your SSH keys by following [these instructions](https://github.com/Microsoft/ostc-docs/blob/master/setup-sshkeys.md). 55 | Once done create a `tar` file that contains your setup files like this: 56 | 57 | ``` 58 | tar cf base-unix.tar .bash_profile .bashrc ssh.tar 59 | ``` 60 | 61 | Keep this `tar` file handy for the steps below. If you have other 62 | configuration files you wish to use (emacs configuration files or 63 | whatever), you can add those to `base-unix.tar` as well. 64 | 65 | ### Set up individual pbuild machines 66 | 67 | Your .pbuild file describes a set of machines that your tests will run 68 | on, in parallel. These machines are typically shared amongst 69 | developers, and support simultaneous builds by multiple developers. 70 | To support this test environment, each developer needs to set up 71 | his/her own account on the test system, and tests are run essentially 72 | using the OpenSSH `ssh` command. 73 | 74 | #### Create User Accounts 75 | 76 | Each test machine needs an account. For ssh to work effectively, the 77 | account name and UID (user ID) should match the user name that you 78 | normally use. For purpose of this document, let's say if your normal 79 | user name is `username`. You should then create a login of `username` 80 | on the pbuild machines. 81 | 82 | Note that our builds routinely require `sudo` operations without a 83 | password prompt. You can edit the `/etc/sudoers` file, but since these 84 | files generally allow allow group `scxdev` to execute commands without 85 | a password, it's easier to make sure you belong to that group. Also, 86 | specific commands may vary between our platforms. 87 | 88 | For these reasons, it's easiest to use [Jeff Coffler's addme script][]. If you 89 | use this script, **be sure to edit** `myuid` and `myuname`, both at the 90 | beginning of the file. 91 | 92 | - Create a user account on the machine: 93 | 94 | ``` 95 | scp ~/bin/addme root@machine_name 96 | ssh root@machine_name 97 | sh ~/bin/addme 98 | rm ~/bin/addme 99 | exit 100 | ``` 101 | 102 | For most Linux/Unix systems, the `addme` script is sufficient to create 103 | the user. On MAC systems, however, th GUI must be used. Use [VNC Viewer][] 104 | to connect to the Mac system 105 | (username `admin`, standard root password) and then use 106 | `System Preferences -> Users & Groups` to create the account. 107 | 108 | - Copy `tar` file to remote system and extract contents 109 | 110 | ``` 111 | scp base-unix.tar ssh.tar machine_name: 112 | ssh machine_name 113 | tar xf base-unix.tar 114 | tar xf ssh.tar 115 | rm base-unix.tar ssh.tar 116 | chmod 700 .ssh 117 | exit 118 | ``` 119 | 120 | - Verify that your account is set up properly with SSH keys 121 | 122 | If you `ssh machine_name`, you should now get no login prompt (you should 123 | be directly logged in). 124 | 125 | Verify proper `sudo` configuration with a command like `sudo ls`, and you 126 | should get no password prompt. 127 | 128 | #### Rince and Repeat 129 | 130 | Now that you have set up one machine in the .pbuild list, you need to 131 | repeat this for every other machine. 132 | -------------------------------------------------------------------------------- /setup-rules.md: -------------------------------------------------------------------------------- 1 | # Guidelines and Rules for Development 2 | 3 | - [Rules](#rules) 4 | - [New to Git?](#new-to-git) 5 | - [Rebase and Fast-Forward Merge Pull Requests](#rebase-and-fast-forward-merge-pull-requests) 6 | - [Submodules](#submodules) 7 | - [How We Use Submodules](#how-we-use-submodules) 8 | 9 | ----- 10 | 11 | ### Rules 12 | 13 | **Do not commit code changes directory to the master branch!** 14 | 15 | **Read the documentation on [submodules][]!** 16 | 17 | **Do not commit submodule updates accidentally!** 18 | 19 | Don't forget to commit early and often! 20 | 21 | 22 | ### New to Git? 23 | 24 | If you're new to Git, learn the following commands: `checkout`, `branch`, 25 | `pull`, `push`, `rebase`, `merge`. 26 | 27 | Use GitHub's [Hello World][] to learn how to create a feature branch, 28 | commit changes, and issue a pull request. 29 | 30 | The user name and email must be set in order to commit changes: 31 | 32 | ```sh 33 | git config --global user.name "First Last" 34 | git config --global user.email "alias@microsoft.com" 35 | 36 | git config --global pull.ff only 37 | git config --global push.default current 38 | ``` 39 | 40 | [submodules]: https://www.git-scm.com/book/en/v2/Git-Tools-Submodules 41 | [hello world]: https://guides.github.com/activities/hello-world/ 42 | [guides]: https://guides.github.com/activities/hello-world/ 43 | 44 | 45 | ### Rebase and Fast-Forward Merge Pull Requests 46 | 47 | Because GitHub's "Merge Pull Request" button merges with `--no-ff`, an 48 | extra merge commit will always be created. This can be especially 49 | annoying when trying to commit updates to submodules. Therefore our 50 | policy is to merge using the Git CLI after approval, with a rebase 51 | onto master to enable a fast-forward merge. If you are uncomfortable 52 | doing this, please ask @andschwa to merge. 53 | 54 | 55 | ### Submodules 56 | 57 | Many of our projects are superprojects with a several 58 | [submodules][]. **DO NOT** commit updates unless absolutely 59 | necessary. Our daily build uses the master branch, and we don't want 60 | to disturb those. When submodules must be updated, a separate Pull 61 | Request must be submitted, reviewed, and merged before updating the 62 | superproject. 63 | 64 | [submodules]: https://www.git-scm.com/book/en/v2/Git-Tools-Submodules 65 | 66 | 67 | 68 | ### How We Use Submodules 69 | 70 | Many of our products are dependent on other projects. We need two 71 | things when we build projects that make use of dependencies: 72 | 73 | 1. Many of our builds require dependent projects to be in known 74 | specific locations so one project can trigger a build of a related 75 | project. For example, several projects are dependent on the 76 | [pal](https://github.com/Microsoft/pal) and/or 77 | [omi](https://github.com/Microsoft/omi), and require those projects 78 | to be at the same directory path as the project itself, and 79 | 80 | 2. For support purposes, we need to be able to identify the specific 81 | sources used to build a complete project, even if the project includes 82 | other common components. This allows us to review actual files used 83 | for the build when defects or bugs are reported. 84 | 85 | That is exactly how we use super-projects and submodules. The 86 | super-project contains the list of all repositories that are to be 87 | used to build the overall project **and** where those projects are 88 | checked out relative to one another, thus satisfying #1 above. 89 | 90 | Since the super-project also contains specific commit hashes for each 91 | subproject used to perform the build, this satisfies #2 above. 92 | 93 | This use of super-projects has the advantage where the super-project 94 | contains the daily commit history for build versioning. Thus, we avoid 95 | cluttering up the source repo(s) with needless daily build commit 96 | history. 97 | 98 | Finally, when cloning, super-projects can be cloned recursively. This 99 | makes it fast and easy to trivially capture all required dependenies 100 | to build a complete project in a single step. 101 | 102 | This is a sharp contrast to our prior use of TFS, where interdependent 103 | projects needed to be set up manually for the build to run properly. -------------------------------------------------------------------------------- /setup-sshkeys.md: -------------------------------------------------------------------------------- 1 | # Setting up SSH Public/Private Keys 2 | 3 | We recommend setting up SSH public/private keys to access UNIX/Linux 4 | systems quickly and effectively: 5 | 6 | 1. [What is a public-private key](#what-is-a-public-private-key) 7 | 2. [How to create a public-private key](#how-to-create-a-public-private-key) 8 | 3. [Keeping remote systems up to date](#keeping-remote-systems-up-to-date) 9 | 10 | ----- 11 | 12 | #### What is a Public-Private key 13 | 14 | SSH (on UNIX/Linux systems) supports login via public/private key. 15 | The idea here is that you never get prompted for username or password 16 | again when logging on to UNIX/Linux systems. It works from putty on 17 | Windows as well, along with SecureCRT and other popular terminal 18 | emulators supporting the SSH protocol. Very, very useful. 19 | 20 | Also, [PBUILD](https://github.com/Microsoft/pbuild) requires use of 21 | public/private keys to work properly. This mechanism only works if you 22 | use a non-shared account. **We do not** recommend that you set this up on 23 | some shared account (i.e. root). 24 | 25 | 26 | #### How to Create a Public-Private Key 27 | 28 | To create a public/private key: 29 | 30 | * Use ssh-keygen. Do this from your “primary” UNIX machine (where you do 31 | most of your development). This will be something like: 32 | ``` 33 | ssh-keygen -t rsa -b 2048 -C "Microsoft-internal" 34 | ``` 35 | 36 | Resulting output will be something like: 37 | 38 | > 39 | ``` 40 | Generating public/private rsa key pair. 41 | Enter file in which to save the key (/home/jeffcof/.ssh/id_rsa): 42 | Enter passphrase (empty for no passphrase): 43 | Enter same passphrase again: 44 | Your identification has been saved in /home/jeffcof/.ssh/id_rsa. 45 | Your public key has been saved in /home/jeffcof/.ssh/id_rsa.pub. 46 | The key fingerprint is: 47 | 68:8e:50:3c:8d:cc:fa:77:2b:ad:cc:88:d6:5f:2f:4a Microsoft-internal 48 | ``` 49 | > 50 | 51 | * In general, we don't recommend the use of a passphrase, although 52 | that is up to you. Most UNIX/Linux systems are shared systems with 53 | sudo access (i.e. inherently insecure). If you do use a passphrase, 54 | then you’ll need to use ssh-agent to cache that (or set up your 55 | [terminal emulator](setup-git.md) to cache that), or you’ll need to 56 | type the passphrase many, many times. We strongly recommend use a 57 | passphrase if connecting remotely and SSH is passed through the 58 | firewall (i.e. when connecting from work to home, that has a 59 | passphrase), or if you're connecting to a secure system. But that’s 60 | not the case here. 61 | 62 | * This will create two files in your .ssh directory: id_rsa and id_rsa.pub 63 | 64 | * Create a link for authorized keys (basically, this is the list of keys 65 | that can be remotely used to log in): 66 | * Create a link from id_rsa.pub with a command like:
67 | `(cd ~/.ssh; ln -s id_rsa.pub authorized_keys)` 68 | * Tar up your .ssh directory: `tar –cf ssh.tar .ssh` 69 | * Copy the ssh.tar file to each of your remote systems and untar it. 70 | * Be sure that the .ssh directory has a permission of 700 or things won’t work! Also, the private key file (id_rsa) must have a permission of 600. 71 | 72 | So, to summarize: Create the public/private key. Copy the key files to each 73 | of your remote systems. On each remote system, .ssh/id_rsa.pub should exist, 74 | .ssh/id_rsa (the private key) should exist, and authorized_keys should exist 75 | and should be a link to .ssh/id_rsa.pub. 76 | 77 | This gets you the ability to SSH and SCP from Linux/Unix system to Linux/Unix 78 | system without password prompts. You can use this same public/private key, 79 | if you wish, to avoid password prompts when SSHing from Windows to UNIX as well. 80 | I do that as well. Same key files work fine. To do this from putty, use the 81 | ‘puttygen’ program to import your key into putty. 82 | 83 | 84 | #### Keeping remote systems up to date 85 | 86 | As an aside, you can keep remote systems up to date via two mechanisms: 87 | 88 | 1. Create some shell scripts to distribute the latest/greatest 89 | .bash_profile file (and any other files you’d like) to a list of 90 | remote systems. This lets you maintain the same environment 91 | everywhere. 92 | 93 | 2. Use something like [dotfiles](https://github.com/jeffaco/dotfiles) 94 | to store important common files. Then a 'git pull' will update your system. 95 | -------------------------------------------------------------------------------- /tfs-migration.md: -------------------------------------------------------------------------------- 1 | # TFS Migration 2 | 3 | The OSTC team has tried several tools to migrate our source 4 | repositories from TFS to Git. We ended up using [Git-Tf] 5 | (https://gittf.codeplex.com/), which did the job. All of the TFS to 6 | Git migrations to date were made using git-tf-2.0.3.20131219.zip. This 7 | can be downloaded via [codeplex](https://gittf.codeplex.com), or can 8 | be copied from: `\\redmond\wsscfs\OSTCData\NixArchive\SourceCodeManagement\git`. 9 | 10 | Some basic observations when using the tool: 11 | 12 | - The tool maintains commit history by doing a commit for each 13 | Teamprise checkin. This can take a while for very active repositories. 14 | 15 | - The tool isn't "great" about memory usage, so it can take a fair 16 | chunk of memory. In general, when running a Linux VM under Hyper-V 17 | using LIS drivers, this doesn't pose any issue. Just be aware of this. 18 | 19 | - The tool will create a tag for each TFS checkin, which we don't 20 | really need. These can be removed with a command like: 21 | `git tag | xargs git tag -d` 22 | 23 | To clone a Teamprise branch to git using git-tf, you must first install 24 | the git-tf tool. This can be done with something like: 25 | 26 | ``` 27 | unzip git-tf-2.0.3.20131219.zip 28 | export PATH=$PATH:`pwd`/git-tf-2.0.3.20131219 29 | ``` 30 | 31 | Then, to run git-tf, you can use a command like: 32 | 33 | ``` 34 | git tf clone http://cdmvstf.corp.microsoft.com:8080/tfs/cdm $/CDM_SFE/Branches/OnPrem/Imp/SCX_Dev/omsagent --deep 35 | ``` 36 | 37 | Note that this does NOT require tfprox. 38 | 39 | Project-specific notes: 40 | 41 | Project | Issue 42 | ------- | ----- 43 | CM | When cloning CM project, some files are too big for github. The test/Tools/SuiteP2 directory contains a large file, and is fortunately no longer required for storage. Rewrite headers in git to eliminate this directory prior to pushing repository up to GitHub. (GitHub has a limit of 100MB for a single file.) 44 | 45 | Other steps after migrating to Git: 46 | 47 | 1. Search for and remove all .tpattributes files, setting the execute 48 | bits via git with a command like `git update-index --chmod=+x `. 49 | 2. Create a .gitignore file to remove build artifacts from `git status` 50 | commands. 51 | 3. Remove any MSBuild-specific files (bootstrap, build/TeamBuildTypes, 52 | etc). 53 | 4. Create a superproject to capture all dependencies, if appropriate. 54 | 5. If a superproject was created, any build version file should live 55 | with the superproject to avoid daily checkins to the active project. 56 | 6. Create a Jenkins build definition on the [Jenkins](http://jenkins-02.scx.com/) 57 | server, verify that it works properly. Take care to only publish bits 58 | that we really need to the build disk; intermediate files should **not** 59 | be published to the build disk. 60 | -------------------------------------------------------------------------------- /workflow-branching.md: -------------------------------------------------------------------------------- 1 | # Git Tagging/Branching Mechanisms 2 | 3 | During regular development, developers will routinely create 4 | [temporary branches](workflow-workflow.md) for code reviews. These 5 | branches are not the focus of this document, as they are generally 6 | short lived (as short as a few minutes, or as long as it takes for a 7 | developer to complete his work). 8 | 9 | When working on branch “master” (equivalent of the improvement branch 10 | on Team Foundation Server, our prior source code management system): 11 | 12 | 1. We will normally have one development stream: Branch “master”. This 13 | is the equivalent of the “improvement” branch in TFS, and represents 14 | our “latest/greatest” code. Most developers work on this branch, or a 15 | sub-branch of this branch, the majority of the time. 16 | 17 | 2. When we need a branch to stabilize a release, we will create a 18 | branch on the fly for that purpose with a meaningful name, and 19 | [cherry-pick](https://git-scm.com/docs/git-cherry-pick) or hand-merge 20 | changes as necessary to make the branch stable. Once stable, a tag 21 | will be created with a meaningful tag for the release and then the 22 | branch can be deleted. As an example, we may create a branch named 23 | "TP5-stabilize". Once the branch is stable and we ship code from it, 24 | we can create a tag named "2016-TP5" and then remove the branch when 25 | it is no longer actively used for development. 26 | 27 | In addition, we’ll have two categories of other branches in our 28 | repositories: 29 | 30 | 1. [Release branches](#release-branches), and 31 | 32 | 2. Long-lived development branches. These would be for a long-lived 33 | development effort (something that several people may work on, or 34 | something that may not be checked in for some period of 35 | time). Eventually, as this work gets merged to the “master” branch 36 | and/or to a “release” branch, the long-lived development branch will 37 | be deleted. 38 | 39 | To manage a long-lived development branch, developers should create 40 | temporary branches off of it. This allows code reviews in manageable 41 | chunks while still allowing the long-lived development branch to be 42 | re-based if needed for ease in future merging. 43 | 44 | ###Release Branches 45 | 46 | In addition to the above, we can have any number of “release” 47 | branches. Examples of such release branches might be 48 | “2016-URNext”. This would be intended as a Update Rollup development 49 | branch for the 2016 release of Operations Manager, for example. 50 | 51 | Note that, in ‘git’, there is a difference for a branch and a tag. A 52 | branch is something long-lived, intended for further checkins, while a 53 | tag is a one-time snapshot of versions of files. 54 | 55 | To further illustrate the difference: A tag represents a version of a 56 | particular branch at a moment in time. A branch represents a separate 57 | thread of development that may run concurrently with other development 58 | efforts on the same code base. Changes to a branch may eventually be 59 | merged back into another branch to unify them. 60 | 61 | Usually you'll tag a particular version so that you can recreate it 62 | (i.e. "v1.1.0-2"). A branch is more of a strategy to provide on-going 63 | updates on a particular version of the code while continuing to do 64 | development on it. 65 | 66 | It is likely that 2016-TP5 (Technical Preview 5) will be a tag off of 67 | the master branch. However, if the master branch is not stable at the 68 | time 2016-TP5 will be produced, we can create a stabilization branch 69 | (as documented above) that will be used temporarily to create a stable 70 | build. 71 | 72 | Meanwhile, as we’re working on “2016-URNext” (a branch), when we 73 | decide to actually ship a UR out of it, we can tag that to be 74 | “2016-UR1” (for the first UR), leaving the “2016-URNext” branch for 75 | further work. Each time we ship code for a supported release, we 76 | create a tag for that release (regardless if the release is off of 77 | 2016-URNext or off of some temporarary stabilization branch). 78 | 79 | Tags can be created either on the master build project (bld-scxcore or 80 | bld-omsagent), called a super-project, or on the individual 81 | repositories involved. Because we need to track all dependencies on a 82 | release, we will create a tag on the super-project (which will 83 | automatically capture all dependencies). Note that we may also choose 84 | to tag a primary project (like OMS-Agent) as well if we want to use 85 | GitHub as a distribution vehicle for the release. 86 | 87 | Finally: Shell bundles, when generated by a project, should support 88 | the “--source-references” qualifier. This qualifier will dump all 89 | relevant git commit hashes (via qualifier “--source-references”) that 90 | went into producing that shell bundle. This makes it very easy to see 91 | exactly what source code the shell bundle represents. 92 | -------------------------------------------------------------------------------- /workflow-hotfix.md: -------------------------------------------------------------------------------- 1 | # Workflow for Creating a Hotfix Release 2 | 3 | Creating a hotfix for a release is very simple. As an example, I'll 4 | use the [OMS project][], creating a mythical hotfix solely for example 5 | purposes. 6 | 7 | The basic steps to creating a hotfix release are: 8 | 9 | 1. [Check in your patches](#check-in-your-patches) 10 | 2. [Using git with more complex code merges](#using-git-with-more-complex-code-merges) 11 | 3. [Set subproject references](#set-subproject-references) 12 | 4. [Set up superproject](#set-up-superproject) 13 | 5. [Build your project with PBUILD](#build-your-project-with-pbuild) 14 | 6. [Create tags and clean up](#create-tags-and-clean-up) 15 | 7. [Create formal release build](#create-formal-release-build) 16 | 17 | All command examples assume you followed [Setting up git][] guidelines. 18 | 19 | ----- 20 | 21 | ### Check in your patches 22 | 23 | For reference, the [OMS project][] has five subprojects: 24 | 25 | 1. dsc 26 | 2. omi 27 | 3. omsagent 28 | 4. opsmgr 29 | 5. pal 30 | 31 | First, you should probably be sure that your projects are completely 32 | up to date, and that you're set to the master branch for each 33 | subproject: 34 | 35 | ``` 36 | cd ~/dev/bld-omsagent 37 | git co-master 38 | git sync-subs 39 | ``` 40 | 41 | For our hotfix, let's assume we need to modify the OMS Agent 42 | configuration file, [omsagent.conf][]. First, we modify the file and 43 | check in the modified result into a new branch: 44 | 45 | ``` 46 | cd omsagent 47 | git checkout -b jeff-hotfix 48 | emacs installer/conf/omsagent.conf 49 | git commit -m "Fix parameters passed to omsadmin.sh for onboarding" 50 | ``` 51 | 52 | Obviously, other changes can be made to other files as part of this 53 | hotfix. 54 | 55 | ### Using git with more complex code merges 56 | 57 | This document assumes a simple change. More complex cases can be 58 | completed by using `git cherry-pick` to get a set of targetted changes 59 | onto your branch, or by using `git merge` to merge in specific commit 60 | hashes. General workflow for this is as follows: 61 | 62 | - Cherry-pick which commit you want added to the current branch: 63 | ``` 64 | git cherry-pick e596ded 65 | ``` 66 | 67 | In case of conflict such as: 68 | 69 | >``` 70 | >error: could not apply 81e0723... 71 | >hint: after resolving the conflicts, mark the corrected paths 72 | >hint: with 'git add ' or 'git rm ' 73 | >hint: and commit the result with 'git commit' 74 | >``` 75 | 76 | then perform one of the following: 77 | 78 | ``` 79 | git status # show which files have conflict, resolve the conflict then commit 80 | git commit -c 81e0723 81 | --or-- 82 | git cherry-pick continue 83 | ``` 84 | 85 | - When you try to cherry pick a merged commit you may get: 86 | 87 | > 88 | >``` 89 | >fatal: Commit e596ded is a merge but no -m option was given. 90 | >``` 91 | > 92 | 93 | To avoid this issue, use merge instead, like this: 94 | 95 | ``` 96 | git merge e596ded 97 | ``` 98 | 99 | ### Set subproject references 100 | 101 | Now that we have a hotfix checked into the [omsagent.conf][] file, we 102 | need to set up other subprojects as desired. For purposes of discussion, 103 | let's say that we need to choose a prior version of [DSC][] than what is 104 | checked into mainline. 105 | 106 | We last left our shell cd'ed into the omsagent subproject. So, we'll 107 | issue a `git lol` command against DSC as follows: 108 | 109 | ``` 110 | cd ../dsc 111 | git lol 112 | ``` 113 | 114 | You'll see output such as: 115 | 116 | >``` 117 | >* a9ccdf5 (HEAD, origin/master, origin/dywu-nxOMSPlugin, origin/HEAD, master) Fix formatting and link in readme 118 | >* 2c3cb16 Update readme.md 119 | >* 6a41725 Update readme.md 120 | >* 087b08f Correct Debian version format of OMI to x.y.z.r (rather than x.y.z-r) 121 | >* d0e6421 (tag: v1.1.1-70) Fix up log rotation for OMI (consider moving to OMI project later) 122 | >* b88c2f7 Explicitly disable -Werror in ./configure 123 | >* 3b8679c Fix compile warnings in EngineHelper 124 | >* 499a8a5 Add instructions to build from source 125 | >``` 126 | 127 | Let's say we don't want to ship the three most recent commits in the 128 | hotfix, instead shipping with "Correct Debian version format" and 129 | earlier. To do so: 130 | 131 | ``` 132 | git checkout 087b08f 133 | ``` 134 | 135 | This will result in output such as: 136 | 137 | >``` 138 | >Note: checking out '087b08f'. 139 | > 140 | >You are in 'detached HEAD' state. You can look around, make experimental 141 | >changes and commit them, and you can discard any commits you make in this 142 | >state without impacting any branches by performing another checkout. 143 | > 144 | >If you want to create a new branch to retain commits you create, you may 145 | >do so (now or later) by using -b with the checkout command again. Example: 146 | > 147 | > git checkout -b new_branch_name 148 | > 149 | >HEAD is now at 087b08f... Correct Debian version format of OMI to x.y.z.r (rather than x.y.z-r) 150 | >``` 151 | 152 | Note that the last line helpfully shows the log message for the commit 153 | hash. This allows you to easily verify that you picked the correct git 154 | hash. 155 | 156 | At this point, go to each of the other subprojects, making sure that 157 | the latest commits are what you want. If necessary, you can exclude 158 | some of the latest commits to the master branch, or you can make edits 159 | to other projects as described under 160 | [Check in your patches](#check-in-your-patches). 161 | 162 | ### Set up superproject 163 | 164 | Change your directory back to the superproject with a command like `cd ..`. 165 | 166 | You need to pick an appropriate version number to build your hotfix 167 | with. One way to achieve this is to bump file `omsagent.version` to a 168 | later version on the master branch. For example purposes, file 169 | `omsagent.version` currently contains: 170 | 171 | >``` 172 | ># -*- mode: Makefile; -*- 173 | >#-------------------------------------------------------------------------------- 174 | ># Copyright (c) Microsoft Corporation. All rights reserved. 175 | >#-------------------------------------------------------------------------------- 176 | ># 2015-10-06 177 | >#-------------------------------------------------------------------------------- 178 | > 179 | >OMS_BUILDVERSION_MAJOR=1 180 | >OMS_BUILDVERSION_MINOR=1 181 | >OMS_BUILDVERSION_PATCH=0 182 | >OMS_BUILDVERSION_BUILDNR=63 183 | >OMS_BUILDVERSION_DATE=20160224 184 | >OMS_BUILDVERSION_STATUS=Developer_Build 185 | >``` 186 | 187 | Edit the `OMS_BUILDVERSION_BUILDNR` tag to a larger number, like 64 188 | (note that a regular build will increment this before building). By 189 | incrementing to 64, that will leave 64 available for your 190 | hotfix. After editing, commit your change to the master branch: 191 | 192 | ``` 193 | git add omsagent.version 194 | git commit -m "Bump omsagent.version file so v1.1.0-64 is available for hotfix" 195 | git push 196 | ``` 197 | 198 | Next, set the `omsagent.version` file as needed for your hotfix to 199 | contain the following lines: 200 | 201 | >``` 202 | >OMS_BUILDVERSION_BUILDNR=64 203 | >OMS_BUILDVERSION_DATE=20160224 204 | >OMS_BUILDVERSION_STATUS=Release_Build 205 | >``` 206 | 207 | We will use v1.1.0-64 for the hotfix, we anticipate our build date to 208 | be 02-24-2016, and this will be a *Release_Build* (not a 209 | *Developer_Build*). 210 | 211 | If you now issue a `git status` command, you'll see output like: 212 | 213 | >``` 214 | ># On branch master 215 | ># Changes not staged for commit: 216 | ># (use "git add ..." to update what will be committed) 217 | ># (use "git checkout -- ..." to discard changes in working directory) 218 | ># 219 | ># modified: dsc (new commits) 220 | ># modified: omsagent (new commits) 221 | ># modified: omsagent.version 222 | ># 223 | >no changes added to commit (use "git add" and/or "git commit -a") 224 | >``` 225 | 226 | The `dsc` and `omsagent` commit hashes have changed due to our changes 227 | above. If other subprojects have changed for your hotfix, be certain 228 | to `git add` those subprojects to capture the changes. Create a new 229 | branch on the superproject and commit all of these files to that 230 | branch: 231 | 232 | ``` 233 | git checkout -b jeff-hotfix 234 | git add dsc omsagent omsagent.version 235 | git commit -m "Hotfix (v1.1.0-64) to resolve onboarding parameters" 236 | git push 237 | ``` 238 | 239 | ### Build your project with PBUILD 240 | 241 | We now have the superproject set up with a branch (`jeff-hotfix`) to 242 | reflect the exact changes that we need to build our hotfix with, but 243 | in terms of the omsagent.verison file and in terms of the commit 244 | hashes for each of the subprojects. 245 | 246 | To test this, you should build your project using [PBUILD][]. Note 247 | that if you invoke PBUILD using the `--branch=jeff-hotfix` qualfier, 248 | then PBUILD will apply all of your changes specfied in the 249 | superproject, with proper commit hashes, prior to performing the 250 | build. 251 | 252 | If there are build failures, fix the sources as needed to resolve them 253 | (consider using `commit --amend` as documented in [Workflow for 254 | Development][] to keep the commit logs clean). Be sure to update the 255 | superproject to the new commit hashes before trying any additional 256 | builds. 257 | 258 | Once you have built successfully and verified that the kit has the 259 | required fixes for your hotfix, you need to *clean up* as specified 260 | next. 261 | 262 | ### Create tags and clean up 263 | 264 | As described in [Git Tagging/Branching Mechanisms][], we don't 265 | generally keep branches around unless they are needed for ongoing 266 | development. As a result, we must delete the temporary branches and 267 | create tags so git will not [garbage collect][] our changes. 268 | 269 | **When creating tags, it is important to pick consisent tag names. For 270 | further information, see [Workflow for Tagging a Release][].** 271 | 272 | In the above example/exercise, the state of our subprojects are as follows: 273 | 274 | Subproject | State 275 | ---------- | ----- 276 | dsc | Chagned to a prior commit hash 277 | omi | No changes from master branch 278 | omsagent | Created new branch, `jeff-hotfix`, for changes 279 | opsmgr | No changes from master branch 280 | pal | No changes from master branch 281 | 282 | We should delete the branches and create tags for each of the 283 | subprojects where files were changed (in this case, `omsagent` and the 284 | superproject itself). 285 | 286 | First, for the omsagent subproject: 287 | 288 | ``` 289 | cd omsagent 290 | git lol 291 | ``` 292 | 293 | will result in output like: 294 | 295 | >``` 296 | >* e971421 (HEAD, origin/jeff-hotfix, jeff-hotfix) Fix parameters passed to omsagent.sh for onboarding 297 | >* a7a0a13 (origin/master, origin/HEAD, master) Adding encoding check function to the output plugin 298 | >``` 299 | 300 | We want to go to the master branch, delete branch `jeff-hotfix` (both 301 | locally and on the server), and create a tag for it instead: 302 | 303 | ``` 304 | git checkout master 305 | git branch -D jeff-hotfix 306 | git rmrbranch jeff-hotfix 307 | git checkout e971421 308 | git tag v1.1.0-64-hotfix 309 | git push --tags 310 | ``` 311 | 312 | Next, we perform the identical procedure to the superproject: 313 | 314 | ``` 315 | cd .. 316 | git checkout master 317 | git branch -D jeff-hotfix 318 | ``` 319 | 320 | Note the output from `git tag -D jeff-hotfix`: 321 | 322 | >``` 323 | >Deleted branch jeff-hotfix (was d30524d). 324 | >``` 325 | 326 | That (helpfully) gives the commit hash that you need to tag: 327 | 328 | ``` 329 | git rmrbranch jeff-hotfix 330 | git checkout d30524d 331 | git tag v1.1.0-64-hotfix 332 | git push --tags 333 | ``` 334 | 335 | You've now deleted all of your temporary branches and created tags, 336 | just one more step! 337 | 338 | ### Create formal release build 339 | 340 | To build this, under Jenkins, we have a special build job called 341 | `OMSAgent-Manual`. This differs from the regular `OMSAgent-Build` job 342 | in two ways: 343 | 344 | 1. It makes no changes at all to omsagent.version, nor to any commit 345 | hashes for subprojects, and 346 | 2. When `OMSAgent-Manual` is run, it prompts for a tag or branch to 347 | build with. 348 | 349 | Run the `OMSAgent-Manual` and supply the tag created during the 350 | [Create tags and clean up](#create-tags-and-clean-up) step above (in 351 | this example, the tag was `v1.1.0-64-hotfix`). This will run the 352 | Jenkins build with that specific tag, creating formal shell bundles 353 | for distribution to customers. 354 | 355 | Since you tested using [PBUILD][] prior to cleanup, there should be 356 | no Jenkins build errors. 357 | 358 | 359 | [Setting up git]: setup-git.md 360 | [Workflow for Tagging a Release]: workflow-tagging.md 361 | [DSC]: https://github.com/Microsoft/PowerShell-DSC-for-Linux 362 | [OMS project]: https://github.com/Microsoft/Build-OMS-Agent-for-Linux 363 | [OMS subproject]: https://github.com/Microsoft/OMS-Agent-for-Linux 364 | [omsagent.conf]: https://github.com/Microsoft/OMS-Agent-for-Linux/blob/master/installer/conf/omsagent.conf 365 | [Git Tagging/Branching Mechanisms]: workflow-branching.md 366 | [garbage collect]: http://think-like-a-git.net/sections/graphs-and-git/garbage-collection.html 367 | [PBUILD]: https://github.com/Microsoft/pbuild 368 | [Workflow for Development]: workflow-workflow.md 369 | -------------------------------------------------------------------------------- /workflow-tagging.md: -------------------------------------------------------------------------------- 1 | # Workflow for Tagging a Release 2 | 3 | Tagging for a release a very simple. There are typically two types of 4 | tagging operations: 5 | 6 | 1. [Tagging the Superproject](#tagging-the-superproject) 7 | 2. [Tagging the Subproject](#tagging-the-subproject) 8 | 9 | Note that when you want to tag the subproject (to publish a release on 10 | GitHub, for example), then you still must tag the superproject, as the 11 | superproject captures all of the actual dependencies. 12 | 13 | Thus, to tag the subproject, you must perform all steps in this 14 | document. 15 | 16 | >**Important: Pick consistent tag names when creating tags!** 17 | >If you fail to to so, then it's harder for cusotmers to find 18 | >predictable tags and potentially link against them. In particular, 19 | >you should avoid sometimes prefixing tags with `v` and sometimes not. 20 | > 21 | >Here's an example of what NOT to do (done for OMS-Agent-for-Linux): 22 | > 23 | >``` 24 | >1.0.0-47 25 | >v1.0.0-47 26 | >v1.1.0-2 27 | >v1.1.0-28 28 | >``` 29 | > 30 | >Tag `1.0.0-47` was created, and external sources linked against 31 | >that. It's traditional for version tags to be prefixed with `v`, 32 | >forcing us to have two tags for the same release. 33 | 34 | 35 | ### Tagging the Superproject 36 | 37 | Our projects usually have superprojects to capture all 38 | dependencies. This allows, for example, DSC to capture dependencies 39 | for DSC itself, omi, and the pal, all of which are required to 40 | properly capture the state of a release. 41 | 42 | We'll use the [DSC project][] as an example to create tags. 43 | 44 | When doing ```git lol``` (if you followed [Setting up git][]) on the [DSC 45 | superproject][], you'll see output such as: 46 | 47 | >``` 48 | >* b574cae (HEAD, origin/master, origin/HEAD, master) Update submodules and version for daily build (v1.1.1-74) 49 | >* 4581e1a Update submodules and version for daily build (v1.1.1-73) 50 | >* f09ee18 Update submodules and version for daily build (v1.1.1-72) 51 | >* 9a3f721 Update submodules and version for daily build (v1.1.1-71) 52 | >* 267290e Update submodules and version for daily build (v1.1.1-70) 53 | >* 7b91046 Update submodules and version for daily build (v1.1.1-69) 54 | >* 6328e68 Update submodules and version for daily build (v1.1.1-68) 55 | >* f29305e Update submodules and version for daily build (v1.1.1-67) 56 | >* 0429b43 Update submodules and version for daily build (v1.1.1-66) 57 | >* 544c0a1 Update submodules and version for daily build (v1.1.1-65) 58 | >``` 59 | 60 | To create a tag for, say, v1.1.1-70, then you need to identify the 61 | commit hash for version v1.1.1-70. Given the log snippet above, that 62 | commit hash is: `267290e`. Given that, first check out the commit hash 63 | that you wish to tag: 64 | 65 | ``` 66 | git checkout 267290e 67 | ``` 68 | 69 | You will get output like the following: 70 | 71 | >``` 72 | >Note: checking out '267290e'. 73 | > 74 | >You are in 'detached HEAD' state. You can look around, make experimental 75 | >changes and commit them, and you can discard any commits you make in this 76 | >state without impacting any branches by performing another checkout. 77 | > 78 | >If you want to create a new branch to retain commits you create, you may 79 | >do so (now or later) by using -b with the checkout command again. Example: 80 | > 81 | > git checkout -b new_branch_name 82 | > 83 | >HEAD is now at 267290e... Update submodules and version for daily build (v1.1.1-70) 84 | >``` 85 | 86 | In particular, note the last line: it shows the commit message for the 87 | commit hash. That's a great way to verify that you have the proper 88 | commit hash. 89 | 90 | Now create a tag for that commit hash in the superproject and push it 91 | to the server: 92 | 93 | ``` 94 | git tag v1.1.1-70 95 | git push --tags 96 | ``` 97 | 98 | That's it. You have now created a tag for the superproject, capturing 99 | all dependencies for that release. Note that this operation can be done 100 | anytime, potentially years after the original release was prepared. 101 | 102 | [Setting up git]: setup-git.md 103 | [DSC project]: https://github.com/Microsoft/PowerShell-DSC-for-Linux 104 | [DSC superproject]: https://github.com/Microsoft/Build-PowerShell-DSC-for-Linux 105 | 106 | ### Tagging the Subproject 107 | 108 | Sometimes we wish to tag the subproject, particularly when GitHub is 109 | used as a release vehicle for specific releases (the subproject is the 110 | project where all the activity happens). To do so, we first go to the 111 | superproject, check out the version tag already created (see above), 112 | and set the submodules to refer to that version: 113 | 114 | ``` 115 | cd bld-dsc 116 | git checkout v1.1.1-70 117 | git submodule update 118 | ``` 119 | 120 | This will fetch v1.1.1-70 of the superproject *and set all of the 121 | subprojects to the approprite git commit hash for that release*. 122 | 123 | Next, you create a tag on the subproject and push it to the server: 124 | 125 | ``` 126 | cd dsc 127 | git tag v1.1.1-70 128 | git push --tags 129 | ``` 130 | 131 | That's it! The subproject now has the appropriate tag for that 132 | version. 133 | 134 | Finally, go to the [DSC Release Page][] on GitHub, create release notes for 135 | that release, and upload the binary packages. 136 | 137 | [DSC Release Page]: https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases -------------------------------------------------------------------------------- /workflow-workflow.md: -------------------------------------------------------------------------------- 1 | # Workflow when Developing with git 2 | 3 | This will serve as a general workflow when doing development on a 4 | project. 5 | 6 | - [Setup](#setup) 7 | - [Code](#code) 8 | - [Pull Requests](#pull-requests) 9 | - [Reviewing Changes](#reviewing-changes) 10 | - [Merge](#merge) 11 | - [Cleanup](#cleanup) 12 | 13 | Other common operations that you may find useful include: 14 | 15 | - [Resolving Merge Conflicts](#resolving-merge-conflicts) 16 | - [Squashing Commit Messages](#squashing-commit-messages) 17 | - [Managing Submodules](#managing-submodules) 18 | 19 | ----- 20 | 21 | #### Setup 22 | 23 | - Most of our repositories have a superproject to capture all 24 | dependencies (Apache, dsc, MySQL, OMS-Agent, and SCXCore are all 25 | examples of this). 26 | 27 | - Fork the repository recursively to get the submodules. The name 28 | of the project will vary based on what you're developing. The table 29 | below is not intended to be exhaustive: 30 | 31 | Project | Super-project Clone Command 32 | ------- | --------------------------- 33 | Apache | ```clone --recursive git@github.com:Microsoft/Build-Apache-Provider.git``` 34 | DSC | ```clone --recursive git@github.com:Microsoft/Build-PowerShell-DSC-for-Linux.git``` 35 | MySQL | ```clone --recursive git@github.com:Microsoft/Build-MySQL-Provider.git``` 36 | OMS-Agent | ```clone --recursive git@github.com:Microsoft/Build-OMS-Agent-for-Linux.git``` 37 | SCXCore | ```clone --recursive git@github.com:Microsoft/Build-SCXcore.git``` 38 | 39 | - If you are contributing in a submodule (dsc, omi, omsagent, opsmgr, 40 | pal, etc) chekout the *master* branch since it is where active 41 | development is being made:
```git fetch; git checkout master```
42 | If you have just cloned the super-project, you can also use an alias 43 | like ```git co-master``` if you followed [Configuring git](setup-git.md) 44 | recommendations. 45 | 46 | - From the master branch, create a feature branch where you will add 47 | your contribution. By convention, for feature branch names, we use the 48 | format ```-```, like:
```git checkout -b 49 | jeff-service``` 50 | 51 | - Commit messages should be no more than about 70 bytes per line. If 52 | you need a longer commit message than that, please use a multi-line 53 | commit message, like this: 54 | 55 | > Short summary of your change 56 | > 57 | > Longer description of your change. This description can contain as 58 | > many lines as needed to describe what you have done. Each line 59 | > should be no more than about 70 bytes in length. 60 | 61 | - Use of 'git rebase' is suggested to keep feature branches up to 62 | date. [Configure git](setup-git.md) for this to work 63 | properly. See [rerere documentation](https://git-scm.com/docs/git-rerere) 64 | and [rebasing documentation](https://www.git-scm.com/book/en/v2/Git-Branching-Rebasing) 65 | for further details, but the general workflow is: 66 | 67 | ``` 68 | git checkout master 69 | git pull 70 | git checkout 71 | git rebase master 72 | ``` 73 | 74 | #### Code 75 | 76 | - Create and switch to a new branch as mentioned above with a command like:
`git checkout -b user-featurename`. 77 | 78 | - Make the changes as needed, test them out 79 | 80 | - Commit the changes: 81 | 82 | ```shell 83 | git add 84 | git commit -m "commit message" 85 | ``` 86 | 87 | - Push the changes to the server:
```git push``` 88 | 89 | - If you need to modify a prior commit, you can amend it (to avoid 90 | squashing commits later) with a workflow like: 91 | 92 | ```shell 93 | git add 94 | git commit --amend -m "commit message" 95 | git push --force 96 | ``` 97 | 98 | If you use `git commit --amend`, an editor will be launched for you 99 | to change the commit message. To use the identical commit message as 100 | earlier, use `git commit --amend --no-edit`. 101 | 102 | - If you do need to squash commit messages, see 103 | [Squashing Commit Messages](#squashing-commit-messages). 104 | 105 | - When your code is tested, you are ready to create a 106 | [Pull Request](#pull-requests) to ask for code reviews. 107 | 108 | #### Pull Requests 109 | 110 | - On the GitHub page for the project that you are modifying, create a 111 | new pull request. The following list is a list of pages for some of 112 | our projects. This list is not intended to be exhaustive. 113 | - [Apache](https://github.com/Microsoft/Apache-Provider) 114 | - [dsc](https://github.com/Microsoft/PowerShell-DSC-for-Linux) 115 | - [MySQL](https://github.com/Microsoft/MySQL-Provider) 116 | - [omi](https://github.com/Microsoft/omi) 117 | - [OMS-Agent](https://github.com/Microsoft/OMS-Agent-for-Linux) 118 | - [pal](https://github.com/Microsoft/pal) 119 | - [SCXcore](https://github.com/Microsoft/SCXcore) 120 | 121 | - The pull request should only show your changes. Be sure there is a 122 | relevant subject for the pull request, and enter any comments to 123 | clarify your changes for the reviewers. Also include an @team mention 124 | to notify your fellow developers of the change.

125 | The @team mention can be satisfied with a line like ```@ostc-devs``` 126 | or ```@omsagent-devs```. See fellow developers to get the team list 127 | that is appropriate for reviews on your project. 128 | 129 | - If you need to make new changes based on review, you can just update 130 | your branch with further commits and ask for additional reviews. 131 | 132 | #### Reviewing Changes 133 | 134 | - Reviewers can sign off by leaving a comment on the *conversation* 135 | tab of the pull request. 136 | 137 | - Experience dictates that Internet Explorer is slow for large pull 138 | requests (with long lists of changes). Chrome is faster for purposes 139 | of reviewing long pull requests. 140 | 141 | - Note that [CodeFlow](http://codeflow/content/workflows-github-pullrequest.html) 142 | now works with GitHub ([CodeFlow](http://codeflow/content/welcome.html) 143 | is a Microsoft internal tool). Give that a try if you prefer that 144 | interface. 145 | 146 | #### Merge 147 | 148 | Once the pull request is reviewed, it can be merged to the master 149 | branch. While github itself can perform the merge easily, it uses the 150 | `--no-ff` option (no fast-forward), resulting in somewhat messy git 151 | logs. **As a result, we do not suggest use of github for merging your 152 | changes.** Instead, we recommend use of the command line. 153 | 154 | - Merge latest changes to your feature branch from the master branch: 155 | ``` 156 | git checkout master 157 | git pull 158 | git checkout 159 | git rebase master 160 | ``` 161 | 162 | - Resolve any merge conflicts that may be necessary. If changes are 163 | necessary, be certain to commit them to your feature branch. If you 164 | need help on how to resolve a merge conflict, see 165 | [below](#resolving-merge-conflicts). 166 | 167 | - Go to the master branch:
```git checkout master``` 168 | 169 | - Merge your changes to the master branch:
```git merge ``` 170 | 171 | - Push the merge to GitHub:
```git push``` 172 | 173 | #### Cleanup 174 | You should clean up your old branches. To do so: 175 | 176 | - Delete remote branch. If you [configured git](setup-git.md), 177 |
```git rmrbranch ``` 178 | 179 | - Delete local branch:
```git branch -d ``` 180 | 181 | #### Resolving Merge Conflicts 182 | 183 | When rebasing your changes to the master branch, you may get a merge 184 | conflict. If that happens, you'll see output like: 185 | 186 | ``` 187 | $ git rebase master 188 | First, rewinding head to replay your work on top of it... 189 | Applying: Add --enable-microsoft to configure, enable native installation kits 190 | Using index info to reconstruct a base tree... 191 | M Unix/configure 192 | :77: trailing whitespace. 193 | case "`uname -m`" in 194 | :82: trailing whitespace. 195 | 196 | warning: 2 lines add whitespace errors. 197 | Falling back to patching base and 3-way merge... 198 | Auto-merging Unix/configure 199 | CONFLICT (content): Merge conflict in Unix/configure 200 | Recorded preimage for 'Unix/configure' 201 | Failed to merge in the changes. 202 | Patch failed at 0001 Add --enable-microsoft to configure, enable native installation kits 203 | The copy of the patch that failed is found in: 204 | /home/jeffcof/dev/bld-omi/.git/modules/omi/rebase-apply/patch 205 | ``` 206 | 207 | When you have resolved this problem, run "git rebase --continue". 208 | If you prefer to skip this patch, run "git rebase --skip" instead. 209 | To check out the original branch and stop rebasing, run "git rebase --abort". 210 | 211 | In this particular case, there was a problem merging changes to file `Unix/configure`. 212 | For merge conflicts, the output from `git status` is very useful: 213 | 214 | ``` 215 | $ git status 216 | # HEAD detached at 05ada53 217 | # You are currently rebasing branch 'jeff-msft-build' on '05ada53'. 218 | # (fix conflicts and then run "git rebase --continue") 219 | # (use "git rebase --skip" to skip this patch) 220 | # (use "git rebase --abort" to check out the original branch) 221 | # 222 | # Changes to be committed: 223 | # (use "git reset HEAD ..." to unstage) 224 | # 225 | # modified: Unix/build.mak 226 | # 227 | # Unmerged paths: 228 | # (use "git reset HEAD ..." to unstage) 229 | # (use "git add ..." to mark resolution) 230 | # 231 | # both modified: Unix/configure 232 | # 233 | ``` 234 | 235 | This clearly shows what your options are (in the first few lines of the status 236 | message). Furthermore, you can see that `Unix/configure` is unmerged. Looking at 237 | this file with an editor will show the follow changes to this file: 238 | 239 | ``` 240 | <<<<<<< HEAD 241 | --show-version) 242 | echo $version 243 | exit 0 244 | ;; 245 | ======= 246 | --enable-microsoft) 247 | enable_preexec=1 248 | prefix=/opt/omi 249 | localstatedir=/var/opt/omi 250 | sysconfdir=/etc/opt/omi/conf 251 | certsdir=/etc/opt/omi/ssl 252 | enable_native_kits=1 253 | 254 | if [ "`uname -s`" = "Linux" ]; then 255 | enable_ulinux=1 256 | fi 257 | ;; 258 | 259 | --enable-native-kits) 260 | enable_native_kits=1 261 | ;; 262 | 263 | --enable-ulinux) 264 | if [ "`uname -s`" != "Linux" ]; then 265 | echo "The --enable-ulinux option is only valid on the Linux platform." 266 | exit 1 267 | fi 268 | 269 | enable_ulinux=1 270 | ;; 271 | >>>>>>> Add --enable-microsoft to configure, enable native installation kits 272 | ``` 273 | 274 | This indicates the changes before your change, as well as the changes that 275 | you have made to the file. Running command `git checkout --conflict=diff3` might 276 | be useful as well. After running the command, the conflict in `Unix/configure` 277 | looks like this: 278 | 279 | ``` 280 | <<<<<<< ours 281 | --show-version) 282 | echo $version 283 | exit 0 284 | ;; 285 | 286 | ||||||| base 287 | ======= 288 | --enable-microsoft) 289 | enable_preexec=1 290 | prefix=/opt/omi 291 | localstatedir=/var/opt/omi 292 | sysconfdir=/etc/opt/omi/conf 293 | certsdir=/etc/opt/omi/ssl 294 | enable_native_kits=1 295 | 296 | if [ "`uname -s`" = "Linux" ]; then 297 | enable_ulinux=1 298 | fi 299 | ;; 300 | 301 | --enable-native-kits) 302 | enable_native_kits=1 303 | ;; 304 | 305 | --enable-ulinux) 306 | if [ "`uname -s`" != "Linux" ]; then 307 | echo "The --enable-ulinux option is only valid on the Linux platform." 308 | exit 1 309 | fi 310 | 311 | enable_ulinux=1 312 | ;; 313 | 314 | >>>>>>> theirs 315 | ``` 316 | 317 | This shows the original (base) change, the change causing the conflict 318 | (labeled as `ours`), and your change (labeled as `theirs`). 319 | 320 | In this particular case, all that's necessary is to remove the markers 321 | added by git (to show the conflict). Both `--show-version` and `--enable-microsoft` 322 | are correct, as follows: 323 | 324 | ``` 325 | --show-version) 326 | echo $version 327 | exit 0 328 | ;; 329 | 330 | --enable-microsoft) 331 | enable_preexec=1 332 | prefix=/opt/omi 333 | localstatedir=/var/opt/omi 334 | sysconfdir=/etc/opt/omi/conf 335 | certsdir=/etc/opt/omi/ssl 336 | enable_native_kits=1 337 | 338 | if [ "`uname -s`" = "Linux" ]; then 339 | enable_ulinux=1 340 | fi 341 | ;; 342 | 343 | --enable-native-kits) 344 | enable_native_kits=1 345 | ;; 346 | 347 | --enable-ulinux) 348 | if [ "`uname -s`" != "Linux" ]; then 349 | echo "The --enable-ulinux option is only valid on the Linux platform." 350 | exit 1 351 | fi 352 | 353 | enable_ulinux=1 354 | ;; 355 | ``` 356 | 357 | At this point, you add the modified file to the commit list and follow 358 | the instructions in the `git status` output: 359 | 360 | ``` 361 | jeffcof:omi> git add Unix/configure 362 | jeffcof:omi> git rebase --continue 363 | Applying: Add --enable-microsoft to configure, enable native installation kits 364 | Recorded resolution for 'Unix/configure'. 365 | jeffcof:omi> 366 | ``` 367 | 368 | Output from `git status` now shows that your merge is complete: 369 | 370 | ``` 371 | > git status 372 | # On branch jeff-msft-build 373 | # Your branch and 'origin/jeff-msft-build' have diverged, 374 | # and have 1 and 1 different commit each, respectively. 375 | # (use "git pull" to merge the remote branch into yours) 376 | # 377 | Nothing to commit, working directory clean 378 | > 379 | ``` 380 | 381 | You can update your branch on the server with a command like `git push --force`. 382 | 383 | To summarize, useful commands when you're trying to resolve a messy merge are: 384 | 385 | Command | Purpose 386 | ------- | ------- 387 | `git checkout --conflict=diff3 filename` | See a lot more context around a set of changes to understand what has changed 388 | `git checkout --ours filename` | Take original changes to a file (and edit your changes in again) 389 | 390 | #### Squashing Commit Messages 391 | 392 | If you committed lots of changes in the scope of a single change (say lots 393 | of iterations), you will likely want to "squash" your commits to a single 394 | commit message appropriate for final checkin. Fortunately, the `git rebase` 395 | command makes this easy. 396 | 397 | As an example, say `git lol` produces output such as: 398 | 399 | ``` 400 | * b69be6f (HEAD, origin/v-brucc-master-pbuild, v-brucc-master-pbuild) Ending comma breaks solaris build 401 | * 3334a09 MI_Application_InitializeV1 not available in libmiapi.a so link libmi.so 402 | * f39d250 line endings break solaris 403 | * 529b908 Return breaks build on solaris 404 | * ab31a8b Changes required by aix 405 | * 27fdc33 More changes for pbuild 406 | * 0f8c298 changes to make pbuild owrk 407 | * 81ebc04 (origin/master, origin/HEAD, master) Removed dos file endings (#73) 408 | ``` 409 | 410 | We can see that commit hashes 0f8c298..b69be6f are all part of a "single 411 | change", and should be squashed to a single commit message. Let's do this 412 | through interactive rebasing with a command like: 413 | 414 | ``` 415 | git rebase -i 0f8c298..b69be6f 416 | ``` 417 | 418 | This could also be done with a command like: 419 | 420 | ``` 421 | git rebase -i HEAD~7 422 | ``` 423 | 424 | to pick up the prior 7 commits. 425 | 426 | This will launch your editor of choice (from `git config` settings) with 427 | output similar to: 428 | 429 | ``` 430 | pick 0f8c298 changes to make pbuild owrk 431 | pick 27fdc33 More changes for pbuild 432 | pick ab31a8b Changes required by aix 433 | pick 529b908 Return breaks build on solaris 434 | pick f39d250 line endings break solaris 435 | pick 3334a09 MI_Application_InitializeV1 not available in libmiapi.a so link libmi.so 436 | pick b69be6f Ending comma breaks solaris build 437 | 438 | # Rebase 60709da..b69be6f onto 60709da 439 | # 440 | # Commands: 441 | # p, pick = use commit 442 | # e, edit = use commit, but stop for amending 443 | # s, squash = use commit, but meld into previous commit 444 | # 445 | # If you remove a line here THAT COMMIT WILL BE LOST. 446 | # However, if you remove everything, the rebase will be aborted. 447 | # 448 | ``` 449 | 450 | As you can see, you have plenty of options available to you from this 451 | screen. To squash everything into one commit, change the first lines 452 | of the file as follows. 453 | 454 | ``` 455 | pick 0f8c298 changes to make pbuild owrk 456 | squash 27fdc33 More changes for pbuild 457 | squash ab31a8b Changes required by aix 458 | squash 529b908 Return breaks build on solaris 459 | squash f39d250 line endings break solaris 460 | squash 3334a09 MI_Application_InitializeV1 not available in libmiapi.a so link libmi.so 461 | squash b69be6f Ending comma breaks solaris build 462 | 463 | # Rebase 60709da..b69be6f onto 60709da 464 | # 465 | # Commands: 466 | # p, pick = use commit 467 | # e, edit = use commit, but stop for amending 468 | # s, squash = use commit, but meld into previous commit 469 | # 470 | # If you remove a line here THAT COMMIT WILL BE LOST. 471 | # However, if you remove everything, the rebase will be aborted. 472 | # 473 | ``` 474 | 475 | This tells git to combine all seven commits into the first commit in 476 | the list. Once this is done and saved, another editor pops up with the 477 | following: 478 | 479 | ``` 480 | # This is a combination of 7 commits. 481 | # The first commit's message is: 482 | changes to make pbuild owrk 483 | 484 | # Thisis the 2nd commit message: 485 | 486 | More changes for pbuild 487 | 488 | # This is the 3rd commit message: 489 | 490 | Changes required by aix 491 | 492 | # This is the 4th commit message: 493 | 494 | Return breaks build on solaris 495 | 496 | # This is the 5th commit message: 497 | 498 | line endings break solaris 499 | 500 | # This is the 6th commit message: 501 | 502 | MI_Application_InitializeV1 not available in libmiapi.a so link libmi.so 503 | 504 | # This is the 7th commit message: 505 | 506 | Ending comma breaks solaris build 507 | 508 | # Please enter the commit message for your changes. Lines starting 509 | # with '#' will be ignored, and an empty message aborts the commit. 510 | # HEAD detached from 0f8c298 511 | # You are currently editing a commit while rebasing branch 'v-brucc-master-pbuild' on 5a6e8f7 512 | # 513 | # Changes to be committed: 514 | # (use "git reset HEAD^1 ..." to unstage) 515 | # 516 | # modified: Unix/base/messages.h 517 | # modified: Unix/build.mak 518 | # modified: Unix/buildtool 519 | # modified: Unix/codec/mof/parser/mof.qualifiers.h 520 | # modified: Unix/codec/mof/parser/moflex.c 521 | # modified: Unix/codec/mof/parser/mofy.redef.h 522 | # modified: Unix/common/MI.h 523 | # modified: Unix/common/common.h 524 | # modified: Unix/configure 525 | # modified: Unix/disp/agentmgr.c 526 | # modified: Unix/mak/rules.mak 527 | # modified: Unix/midll/GNUmakefile 528 | # new file: Unix/midll/libmi.exp 529 | # modified: Unix/pal/palcommon.h 530 | # modified: Unix/providers/identify/GNUmakefile 531 | # modified: Unix/tests/codec/mof/blue/consts.c 532 | # modified: Unix/tests/codec/mof/blue/test_lex.cpp 533 | # modified: Unix/tests/codec/mof/blue/test_mofserializer.cpp 534 | # modified: Unix/tests/codec/mof/blue/test_parser.cpp 535 | # 536 | ``` 537 | 538 | Since we're combining so many commits, git allows you to modify the 539 | new commit's message based on the rest of the commits involved in the 540 | process. Edit the message as you see fit, as shown below: 541 | 542 | ``` 543 | Changes to build & run regress on AIX, HP, and Solaris platforms 544 | 545 | # Please enter the commit message for your changes. Lines starting 546 | # with '#' will be ignored, and an empty message aborts the commit. 547 | # HEAD detached from 0f8c298 548 | # You are currently editing a commit while rebasing branch 'v-brucc-master-pbuild' on 5a6e8f7 549 | # 550 | # Changes to be committed: 551 | # (use "git reset HEAD^1 ..." to unstage) 552 | # 553 | # modified: Unix/base/messages.h 554 | # modified: Unix/build.mak 555 | # modified: Unix/buildtool 556 | # modified: Unix/codec/mof/parser/mof.qualifiers.h 557 | # modified: Unix/codec/mof/parser/moflex.c 558 | # modified: Unix/codec/mof/parser/mofy.redef.h 559 | # modified: Unix/common/MI.h 560 | # modified: Unix/common/common.h 561 | # modified: Unix/configure 562 | # modified: Unix/disp/agentmgr.c 563 | # modified: Unix/mak/rules.mak 564 | # modified: Unix/midll/GNUmakefile 565 | # new file: Unix/midll/libmi.exp 566 | # modified: Unix/pal/palcommon.h 567 | # modified: Unix/providers/identify/GNUmakefile 568 | # modified: Unix/tests/codec/mof/blue/consts.c 569 | # modified: Unix/tests/codec/mof/blue/test_lex.cpp 570 | # modified: Unix/tests/codec/mof/blue/test_mofserializer.cpp 571 | # modified: Unix/tests/codec/mof/blue/test_parser.cpp 572 | # 573 | ``` 574 | 575 | Save the file and exit the editor. Once that's done, your commits have 576 | been successfully squashed! 577 | 578 | If we now do a `git log`, we see output such as: 579 | 580 | ``` 581 | commit 5a6e8f7 (HEAD, v-brucc-master-pbuild) 582 | Author: Bruce Campbell 583 | Date: Fri Sep 23 09:56:16 2016 584 | 585 | Changes to build & run regress on AIX, HP, and Solaris platforms 586 | 587 | commit 81ebc04 (origin/master, origin/HEAD, master) 588 | Author: Bruce Campbell 589 | Date: Wed Sep 21 07:50:34 2016 590 | 591 | Removed dos file endings (#73) 592 | ``` 593 | 594 | The `git status` command indicates: 595 | 596 | ``` 597 | # On branch v-brucc-master-pbuild 598 | # Your branch and 'origin/v-brucc-master-pbuild' have diverged, 599 | # and have 1 and 7 different commits each, respectively. 600 | # (use "git pull" to merge the remote branch into yours) 601 | # 602 | nothing to commit, working directory clean 603 | ``` 604 | 605 | Because the `v-brucc-master-pbuild` branch is now divergent from 606 | the server branch (as indicated in the above status output), the 607 | branch must be force-pushed to the server: 608 | 609 | ``` 610 | > git push --force 611 | Counting objects: 72, done. 612 | Delta compression using up to 2 threads. 613 | Compressing objects: 100% (34/34), done. 614 | Writing objects: 100% (37/37), 7.99 KiB | 0 bytes/s, done. 615 | Total 37 (delta 28), reused 5 (delta 2) 616 | remote: Resolving deltas: 100% (28/28), completed with 28 local objects. 617 | To git@github.com:Microsoft/omi.git 618 | + b69be6f...3d49ff1 HEAD -> v-brucc-master-pbuild (forced update) 619 | > 620 | ``` 621 | 622 | #### Managing submodules 623 | 624 | Assuming you [configured git](setup-git.md), the following 625 | show common ways to manage all the submodules (all from the 626 | super-project): 627 | 628 | ```shell 629 | # Switch to the master branch 630 | git co-master 631 | 632 | # Pull latest changes, delete stale remote-tracking branches 633 | git sync-subs 634 | 635 | # Show commit references for all the branches 636 | git submodule foreach git branch -vv 637 | ``` 638 | --------------------------------------------------------------------------------