Contribute to the code
To contribute to the development of Singularity, you must:
- Own the code and/or have the right to contribute it
- Be able to submit software under the 3 clause BSD (or equivalent) license (while other licenses are allowed to be submitted by the license, acceptance of any contribution is up to the project lead)
- Read, understand and agree to the license
- Have a GitHub account (this just makes it easier on me)
Step 1. Fork the repo
To contribute to the web based documentation, you should obtain a GitHub account and fork the Singularity repository. Once forked, you will want to clone the fork of the repo to your computer. Let’s say my Github username is vsoch, and I am using ssh:
git clone git@github.com:vsoch/singularity.git
cd singularity/
Step 2. Set up your config
The github config file, located at .git/config, is the best way to keep track of many different forks of a repository. I usually open it up right after cloning my fork to add the repository that I forked as a remote, so I can easily get updated from it. Let’s say my .git/config first looks like this, after I clone my own branch:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:vsoch/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
I would want to add the upstream repository, which is where I forked from.
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:vsoch/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "upstream"]
url = https://github.com/singularityware/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
I can also add some of my colleagues, if I want to pull from their branches:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:vsoch/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "upstream"]
url = https://github.com/singularityware/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "greg"]
url = https://github.com/gmkurtzer/singularity
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
This would mean that I can update my master branch as follows:
git checkout master
git pull upstream master
git push origin master
Step 3. Checkout a new branch
Branches are a way of isolating your features. For example, if I am working on several features, I would want to keep them separate, and “submit them” (in what is called a pull request) to be added to the main repository codebase. Each repository, including your fork, has a main branch, which is usually called “master”. THe master branch of a fork should always be in sync with the repository it is forked from (which I usually refer to as “upstream”) and then branches of the fork consistently updated with that master. Given that we’ve just cloned the repo, we know that we are in sync with master, and can immediately checkout a new branch
# Checkout a new branch called add/my-awesome-feature
git checkout -b add/my-awesome-feature
The addition of the -b argument tells git that we want to make a new branch. If I want to just change branches (for example back to master) I can do the same command without -b:
# Change back to master
git checkout master
Note that you should commit changes to the branch you are working on before changing branches, otherwise they would be lost. Github will give you a warning and prevent you from changing branches if this is the case, so don’t worry too much about it.
Step 4. Make your changes
On your new branch, go nuts! Make changes, test them, and when you are happy with a bit of progress, commit the changes to the branch:
git commit -a
This will open up a little window in your default text editor that you can write a message in the first line. This commit message is important - it should describe exactly the changes that you have made. Bad commit messages are like:
- changed code
- updated files
Good commit messages are like:
- changed function “get_config” in functions.py to output csv to fix #2
- updated docs about shell to close #10
The tags “close #10” and “fix #2” are referencing issues that are posted on the main repo you are going to do a pull request to. Given that your fix is merged into the master branch, these messages will automatically close the issues, and further, it will link your commits directly to the issues they intended to fix. This is very important down the line if someone wants to understand your contribution, or (hopefully not) revert the code back to a previous version.
Step 5. Push your branch to your fork
When you are done with your commits, you should push your branch to your fork (and you can also continuously push commits here as you work):
git push origin add/my-awesome-feature
Note that you should always check the status of your branches to see what has been pushed (or not):
git status
Step 6. Submit a Pull Request
Once you have pushed your branch, then you can go to either fork and (in the GUI) submit a Pull Request. This will open up a nice conversation interface / forum for the developers of Singularity to discuss your contribution, likely after testing. At this time, any continuous integration that is linked with the code base will also be run. If there is an issue, you can continue to push commits to your branch and it will update the Pull Request.
Support, helping and spreading the word!
This is a huge endavor, and it is greatly appreciated! If you have been using Singularity and having good luck with it, join our Google Group and help out other users! Post to online communities about Singularity, and request that your distribution vendor, service provider, and system administrators include Singularity for you!
Edit me