Getting Started: Making a PR or Commit via Github

Github

If you haven’t been invite to our Github team yet send a message or tag @trust_level_4 and someone will help you out.

Live Branches

Making PRs and Commits to the Reactjs app

  • Master staging server to test all commits
  • Changes are pushed downstream to all deployed branches in batches on a roughly monthly basis. Urgent bug fixes will get merged immediately.

Please merge all PRs to Master, unless you have some reason (emergency fix?) to promote commits directly to a production server without first deploying them to the testing server.

Changes should be deployed to production branches all together on a monthly basis, unless they are urgently needed.

When you want to deploy changes that have reached master you can use the git branch -f commands as above to update one or both deployment branches, either to the latest Master, or any “known good” commit you want to promote.

I would recommend only ever pointing the deploy branches either at the master branch’s HEAD, or at a commit that is in the master branch’s history, to avoid creating a confusing situation, or ending up back in the situation where you have a different branch for each website.

If you do ever commit something directly to a deployment branch (e.g. for an emergency hotfix) please merging that deployment branch into the Master branch afterwards to bring everything together again.

Coding changes to the Ruby on Rails site

Changes to the Ruby on Rails site are coded as Discourse Components, Themes or Plugins, under this order of preference as Components are the most flexible and easy to use.

To test your code you will need an admin of the testing and development site to add it via the Discourse admin section. If its a plugin you’ll also need someone in the @SysAdmin team to add it via command line on our server following this guide.

Please keep any Components, Themes, or Plugins, under our Focallocal umbrella in Github so others can find it easily, and also create documentation on your build in our forum here, to make it easier if others want to expand on your work later. (make a new post with the tags ‘rubyonrails’ ‘discourse’ ‘documentation’ ‘webdev’ ‘your codes name’ ‘what your code does’)

When building on an existing plugin/component or theme we try where possible to bring the author onboard and get them to include our improvements in their main code, to increase the likely-hood it will be updated by them or others in the future, and to share our work with the wider community.

They can be found and contacted via the forums at https://meta.discourse.org/

@zofrex I created this from your message to me. Can you see anything which needs to be added for this to be useful documentation?

Currently our tests are broken and failing. You can ignore those. If someone would like to fix them please do.