Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Read and follow Testing Locally!
This includes the setup of Ruby and the ability to build and inspect the website locally!
Add the pull request Git refs to your local Git clone.
In your local copy of the website (e.g. in
$HOME/projects/jlesc.github.io), as you have set up according to Basic Setup, edit
.git/configand find the section for the
upstreamrepository and adjust it to match the following:
[remote "upstream"] url = firstname.lastname@example.org:JLESC/jlesc.github.io fetch = +refs/pull/*:refs/remotes/upstream/pr/* fetch = +refs/heads/*:refs/remotes/upstream/*
The important part is the first
fetch-line. This allows you to checkout the changeset of a pull request locally without adding the source repository of the PR, i.e. the contributor's fork, as a remote.
(optional but handy)
git fetch --all --prune, at least for this repository.
(optional but strongly recommended)
Make sure your GPG keys are working with Git for GPG-signed commits.
That way we can always make sure the sources of the JLESC website are genuine.
A New Pull Request is Created
Whenever some contributor creates and opens a pull request (PR), you - the maintainer of jlesc.github.io - is asked for action! *hurray* We advice you to follow these steps closely to avoid future issues.
Check, whether the contributor has followed the advised steps in "Contributor's Workflow" including the naming of branches.
Wait for Travis to build and test the PR!
You will see some basic information alongside the PR whether the build is currently running (orange dot), has successfully finished (green checkmark) or failed (red cross).
Inspect the Build
Wait and keep reloading every few minutes.
In general, it should not take Travis more than two to three minutes to complete the build.
Inspect the build log for errors!
On the PR's page you will find a link to Travis' output for further inspection.
Once you identified the error, comment on the PR and ask the contributor for a fix and stay tuned to help him/her out.
Inspect the build log for suspicious output!
Never trust your contributors!
We now assume, the build has succeeded!
Before merging the PR, you should inspect and test it locally
On your computer
Update all refs (see also point 2 of the preparations):
git fetch --all --prune
git checkout source
Make sure nothing lays around:
Should tell you everything is clean.
git merge --no-commit --no-ff --log upstream/pr/<PR_NUMBER>/head
PR_NUMBERis the issue number of the pull request as displayed by GitHub.
This will merge the full changeset of the PR into your local source branch without committing it. Thus, you will be able to inspect the changes and potentially fix some minor issues not worth bothering the contributor with, e.g. minor whitespace mistakes in
Inspect the changelog and diff of all commits in the PR for any wanky lines!
Minor typos or whitespace inconsistencies you should fix yourself. Bigger issues you should report back to the contributor by commenting on the PR.
Build, run and test the site locally:
bundle exec jekyll serve --watch --incremental --trace
Open your browser at http://127.0.0.1:4000/.
Assuming everything's fine, now either commit the merge locally and push it to GitHub:
git commit --signoff -S git push
In case the PR isn't fine yet, ABORT THE MERGE
git merge --abort
and contact the contributor or leave him/her a comment within the PR.