Who this workflow is for
This page describes the workflow for Infra members with Git repo commit access.
If you do not have commit access, please fork our repo on GitHub and issue a Pull Request - the system notifies us and will respond in a timely manner.
Shuld your PR nt be reslved within a reasnable time, pen a Jira ticket and link it t the PR. In general we triage PRs by the importance of the issue they report, as in Jira.
Terms and Definitions
CTR: (Commit-Then-Review)
Perform the commit and the Infra team will review it when prompted by the commit email.
Commit emails come to the commits@infra.apache.org mailing list.
svn changes generally use a CTR workflow.
RTC: (Review-Then-Commit)
A review is needed before a commit is made.
infrastructure-puppet[6] changes use the RTC workflow.
Repository Notes
The infrastructure-pupper repo is hosted at https://gitbox.apache.org/repos/infrastructure-puppet.git and mirrored at https://github.com/apache/infrastructure-puppet .
deployment is the production branch.
There is a Buildbot job to check syntax, set up as a post-receive hook.
NOTE: Deployment branch is currently locked, only root can push to it!
For Infra folks with commit bit - the current workflow to use goes something like this.
Working on the infrastructure-puppet repo
git clone https://gitbox.apache.org/repos/asf/infrastructure-puppet.git if you haven't already.
Since this repo is on GitBox, you can push to GitBox or GitHub, but it's best to choose one and stick to it.
Ensure you have deployment branch up-to date.
git checkout deployment
git pull
DO NOT use master. It is not used any more and changes pushed to master will be ignored.
Working on your branch
git checkout -b $yourbranch
(do some amazing coding.)
Do some lint checking:
bin/syntax_check
bundle exec puppet-lint modules/ [1]
git add .
git commit [-S] -m "changes to my branch" (Consider using -S to have your commit(s) verified [2])
git push origin $yourbranch # ALWAYS specify what branch you're pushing to!
(Ask an active Infra member to approve (+1) your branch and either they will merge it or you can self-merge quoting the +1 and its author in the log message.)
Pull requests
once you've made a branch, feel free to just make a pull request on GitHub https://github.com/apache/infrastructure-puppet/pull/new/deployment.
GitHub is pretty smart and will recognize branches you've made to select against.
This is can be a better method for merging large changes that require discussion or are more asynchronous across time zones/ etc.
Get someone else to review and merge your code so we have more eyes on it.
OF Changes (Obvious Fix)
There are small “Obvious Fix [OF]” changes that can be “self-merged”. Changes of this type include (but are not limited to) fixing typos and syntax, and comment updates. OF changes should have “OF” in the log message, and can be done at your discretion.
Merge your own branch in case of emergency
Important: This means having to merge without a +1 from anyone else. Nobody has reviewed your branch and nobody is around to do so and the
branch is in need of immediate merge. i.e. some service is down and needs it. LEAVE A NOTE IN THE COMMIT MESSAGE.
git pull
git checkout deployment
Do some lint checking:
bundle exec puppet-lint modules/ [1]
git merge origin/$yourbranch # will provide you an opportunity for a commit message
git push origin deployment # ALWAYS specify what branch you're pushing to!
Merging others branches (approve + merge) (default workflow)
git pull
git checkout $theirbranch
Do some lint checking:
bundle exec puppet-lint modules/ [1]
git checkout deployment
git merge origin/$theirbranch # may provide you an opportunity for a commit message
git push origin deployment # ALWAYS specify what branch you're pushing to!
Keeping your branch in sync with deployment (a/k/a rebase)
git pull
git checkout $mybranch
git rebase deployment
(fix any merge conflicts by using git status for what needs to be done and asking those in #asfinfra)
git push origin $mybranch # ALWAYS specify what branch you're pushing to!
Merging Conflicts
something like (whilst on your branch) :
git rebase deployment
(edit and resolve conflicts, the stuff between <<<<<<< HEAD and >>>>>>> $branch)
git add $conflicted_file(s)
git rebase --continue
Cleaning up after yourself (deleting your merged branch)
(delete branch locally after merge)
git branch -d $branch (it may complain, and if so, use -D)
(delete branch on remote)
git push origin :$branch
Links to external resources
Resolving merge conflicts in many more situations
More tips on cleaning up branches etc.:
Footnotes
Sign your commits with your GPG key
Consider using 'git commit -S -m "blah"' when committing. That is use -S in conjunction with your GPG key to have your commits verified.
- Add 'signingkey = YOURKEY' to your .gitconfig file (example Daniel Takamori would use 'signingkey = E2BA6F3F'
- Add your GPG key to your Github Settings
- Make your commits with the -S flag
to make the setting permanent per repo run this command in your repo:
git config commit.gpgsign true
No need to remember the -S switch then.
For more info see : this GitHub article on GPG signing your commits.
Prepare for lint checking
From root of puppet repo on deployment branch, run
gem install bundler
From root of puppet repo on deployment branch, run
bundle install
To check again puppet-lint, run
bundle exec puppet-lint modules/
For finer grained lint checking ignoring stuff we cant do much about currently use (and tweak as needed)
bundle exec puppet-lint --no-nested_classes_or_defines-check --no-autoloader_layout-check modules/
gem install yaml-lint yaml-lint data/nodes/name-of.yaml yaml-lint data/nodes (leave out filename to check them all)
Other tips:-
In Vim to remove all trailing whitespaces from all lines in a file:-
:%s/\s\+$//
Recently upgraded your Mac?
Having just upgraded from Sierra to High Sierra - to be able to edit eyamls again and other stuff I had to:-
gem install bundler # cd to your infrastructure-puppet git checkout bundle install xcode-select --install # optional: gem install ruby_gpg
ruby_gpg is possibly optional, try without it first if you like.
Now, you should have a fully-working setup. (If not, add here what else you had to do!)
email users@infra.apache.org
for any queries or suggestions.