How to contribute code
This guide explains how to contribute code to a Nasqueron project.
We use Phabricator for tasks and code reviews, our instance is called DevCentral and is accessible at https://devcentral.nasqueron.org.
In a nutshell, to submit a change, you need to clone the relevant repository, create a new branch, commit and send this commit to our code review server. Pull requests on GitHub could be fine for trivial hit and run patches, but if you add a new feature, use our code review server.
Clone the repository
On DevCentral, go to Diffusion. Each repository will offer you a clone command.
For example, it could be:
git clone ssh://vcs@devcentral.nasqueron.org:5022/someproject
Most projects are directly hosted on DevCentral. In this case, you need to add your SSH key to the settings.
If the repository is on GitHub but not on DevCentral, please request it to be added. For that, create a task on DevCentral and add DevCentral as project.
If you want to edit a Keruald library, clone the monorepo and not directly the read-only repo of the library. This is intended to ease development across dependent libraries.
Code something
Never work in Git main branch, when you are submitting new code.
Always create a new branch for each change, code feature or bug fix.
The main branch is only to merge changes, not to work.
Trust us, you want to code and have fun, not to spend an evening to fix your Git repositories merging infinite conflicts.
Remember: One new change, one new branch.
To fix a bug, or code a new feature, three operations are needed:
- code it
- commit it
- review it
Code it
Before to start to code, create a new branch:
git checkout -b feature/something-awesome
If you fix a bug, use the number of the bug on DevCentral:
git checkout -b bug/T434
Then code something, test it, reread it.
Commit it
When you're ready, you can commit it.
Your commit message should use the following format:
- a title, as short as possible, with 43 max characters recommended, 55 characters as soft limit, 72 as hard limit
- some paragraphs, but wrap lines < 72 characters. You can extend at 80 (soft limit) or 100 (hard limit) if really needed.
The title should be at imperative, not followed by a final dot.
The paragraphs should focus to explain why this change is needed.
See http://chris.beams.io/posts/git-commit/ for more best practices.
Review it
arc diff
This will send your change on DevCentral, and allow the review process to start.
When you use `arc diff`, Arcanist will try to guess what change you want to offer. If you've committed in a branch, it will guess correctly you want to submit the diff between main and this branch (your commit).
You'll find more information about this on the Phabricator documentation.
Once reviewed, your change will be live in the main repository. Cheers!
Edit a change
To edit the change, amend the relevant commit.
git checkout <the relevant branch> [change something] git add <the files modified> git commit --amend arc diff
If arc complain, try:
arc diff --update <differential id without D prefix>
You can also use the web interface: Differential allows you to submit a patch to amend your change.
In this case, you edit the files, run `git diff` and copy/paste the result on Phabricator.
You can now go on to code
Meanwhile review, you can go to another branch and go on to work.
If this change is independent, your new branch must start at main, not at your previous branch:
git checkout main git checkout -b feature/another-awesome-change
But when your change depends of the previous one, you create a new branch from the last:
git checkout -b feature/the-next-change
Then again, code, commit, and send to review with arc diff.
Review code
Where are reviews and what can I do there?
Reviews are accessible at Differential.
In the bottom of a revision page, you'll find a action menu to accept a revision or request changes.
You can also comment inline, clicking on line numbers.
Everyone can offer comment.
Accept a revision
Don't self review, ie don't accept your own revisions.
Consider to land accepted revisions immediately.
Note: for Salt, that works slightly differently: a test deployment is required before landing, and self review is allowed when a member of the team is alone, and the matter trivial or urgent.
What does that mean?
An accepted revision is a revision ready to be integrated into the code base (the goal of the CI process), and so to be sent to production environment.
Some projects trigger automatically a new deployment step after a commit has been integrated, for example the Docker images are all configured to rebuild a new image from the latest tag. Websites like https://docker.nasqueron.org/ or https://assets.nasqueron.org/ are also automatically updated.
By accepting a revision, you express your confidence it's ready and sounds safe to deploy.
Does your project have special guidelines for code review?
- If so, follow them.
- If not, any member considering themself a member of the project can accept any revision from another project member.
Next step is to land the accepted revision. This currently requires arc land, but we're working to allow to land from the web UI.
Merge the revision to main
In Phabricator language, that's called land the revision.
- Use a clean and up-to-date main:
git fetch && git checkout main && git reset --hard origin/main - Get the patch:
arc patch D300 - Merge the patch to main:
arc land
The differential UI gives the next step in the header.
After the merge
Stay reachable and watch the post commit actions (e.g. does the Docker image has been successfully built on Docker Hub?). Be ready to use git revert to revert the change if something is wrong.
When can I self review?
Self review is frowned upon, but in two cases it could be needed:
- when there is an emergency, for example to fix a security issue, when no one in duty can be found;
- when you're alone on your project, and can't find someone to review.
How to revert a change?
A change revert is a commit:
- you can automatically create by
git revert <commit-ish> - you craft manually, like any other change
Then, you follow the exact same instructions you would for a regular change: send to the code review, review it, land it.
The revision should be accepted by:
- the original commit author if present at deployment time
- someone you work with to solve currently the issue if the author isn't there
- yourself if you're alone
The review should contain a comment about what is broken in the reverted commit, excepted if there is already such information in Audit or Differential.
Troubleshoot Arcanist
Use Nasqueron maintained patches
If you wish to get upstream + a patch to use by default main and not master branch name + PHPUnit support you can clone the production branch at https:/github.com/nasqueron/arcanist (it's the default branch).
PHPUnit7+ support
You can apply this patch to get a working Arcanist on the upstream version:
$ file `which arc`
$ cd /path/to/arcanist
$ arc install-certificate
$ arc paste P2084 | patch -p1
On Debian, the path to Arcanist is /usr/share/arcanist when installed through a package.
If you wish to maintain it against last Arcanist release:
$ git checkout -b production
$ git commit -a -m "Support PHPUnit 7+"
