Skip to content
JS Ng edited this page Jan 3, 2025 · 11 revisions

To contribute to this page, contact Mr Ng to be added as a collaborator.

Commit workflow

  1. Clone the repository url: https://github.com/nyjc-computing/nyjc-computing.github.io.git in VSCode, or use a Codespace (requires verification through Github Education for free access).
  2. Commit and push any changes to a separate branch; name the branch issue-XXX where XXX is the issue number.
    • If an issue doesn't exist for the task you are working on, create one first. This facilitates discussion and pull request tagging.
    • The issue page has a link to "Create a branch for this issue", use it.
  3. Make a pull request to content or dev depending on the nature of the change:
    • For content edits (e.g., Markdown updates):
      • Branch Name: issue-XXX
      • Target Branch: content
    • For development edits (e.g., HTML templates, CSS, or config files):
      • Branch Name: issue-XXX
      • Target Branch: dev
  4. Do not make pull requests directly to main. All changes should go through content or dev, and then be merged into main.

Building the site locally

  1. Make changes.
  2. Run the following command: bundle exec jekyll serve
    • You may need to run bundle install to install project dependencies first.
  3. It should provide a local URL (default: http://localhost:4000/) for browsing site contents. In Codespaces, this will also open a webview.

Existing Automations

Automations have been set up that you should be aware of:

  1. Integration test: Every pull request to content or dev branches will trigger a build script (bundle exec jekyll build) that checks if the site can be built. IF this test fails, the pull request should not be approved until the problem is resolved.
  2. Deployment: Every approved pull request to main triggers the deployment process: Github Actions will build the site, then deploy the rendered pages.
  3. Downstream branch synchronisation: Whenever main is updated, a workflow is triggered to synchronise changes from it to content and dev. This aims to ensure that content and dev do not become outdated. This is not done for your own respective branches, so be sure to merge changes from content and dev to your own feature branches.

What to contribute?

  1. See project issues for places that need help.
  2. Suggest any improvements by creating a new issue for discussion (apply the question label).
  3. Issues tagged good first issue are a good way to get yourself eased into the development process.
Clone this wiki locally