Updating the Website

From All Hands Active Wiki
Jump to navigation Jump to search

We use Github pages to host our website. It is populated from the content checked into our Github site repo here: https://github.com/allhandsactive/site (which links to https://allhandsactive.github.io/site/ or https://allhandsactive.org). There is also a test site located here: https://github.com/allhandsactive/site-test (populates https://allhandsactive.github.io/site-test/).

Generally, you will be making changes in the test site, which either James K. or Nate Y. will bring over once they are looking good. However, in case both of them are tragically clobbered by a falling pressure tank from a faulty SpaceX de-orbit, the following instructions should help you get the changes into production:

To make changes to testing:

GitHub based

  1. Edit files as needed in the GitHub interface.
  2. You can check the changes to see how they look over on the testing site at https://allhandsactive.github.io/site-test/ .

Git based

  1. Clone the testing repo:
  2. Make whatever changes you are wanting to in this repo. You can use a branch if you wish, but we don't have a PR process for testing, and will ultimately be cherry-picking changes to bring over the production. If you can avoid generating a ton of commits to accomplish your work, this process will ultimately be much easier. :)
  3. When you are done making changes and want to see how the changes look, commit and push the changes into the testing repo using git add, git commit, etc.. If you aren't using a branch, you can push directly to master with:
    • git push origin master
  4. You can check the changes to see how they look over on the testing site at https://allhandsactive.github.io/site-test/ .

The process to promote changes from testing to production:

  1. Clone the production repo. We won't be making changes directly in here, but will add the testing repo under it:
  2. While in the production repo's directory, add the testing repo with the following command. You will need to have a github SSH key installed (see https://docs.github.com/en/github-ae@latest/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent on how to do this):
    • git remote add test git@github.com:allhandsactive/site-test.git
  3. Now fetch the branch from the testing repo:
    • git fetch test
  4. Switch to the testing repo's master branch:
    • git checkout test/master
  5. Verify you are in the correct spot by checking the logs with git log.
  6. Make a record of changes that need to come over based on your commit hashes in the log.
  7. Once you've got the list of your changes, switch back to the production master:
    • git checkout origin/master
  8. Make a new branch for cherry-picking the changes from testing over to production, e.g.:
    • git checkout -b enhancement/<some-clever-branch-name>
  9. Cherry-pick the hashes of the changes you are bringing over from testing. IMPORTANT: make sure you are cherry-picking in the order of OLDEST to NEWEST change, so you will likely have to go from bottom to top of the list you created previously. Do this on each hash by running:
    • git cherry-pick <hash>
  10. Resolve any merge conflicts you find along the way e.g. with "git mergetool". Once you have finished, push the changes into a new branch on the production repo:
    • git push origin enhancement/<some-clever-branch-name>
  11. Now create a new PR on the pushed branch, assign a reviewer, and add a description to reflect your PR's goal:
    • Check on your changes here https://github.com/allhandsactive/<project>/branches
    • Click on the Make a new Pull Request button
    • Assign a reviewer using the right-hand bar (artlogic or l0gik)
    • Fill in some details about your change. Useful info would include if it is supposed to fix a specific issue (e.g. "Proposed fix for #<issue_number>").
    • Submit the PR for approval by the assigned reviewer.
    • Once the PR has been reviewed and approved, you can verify it made it through in the commit history, test it, etc..
  12. Once the PR is approved, the site will rebuild, and the changes should be live soon after.