Home
Welcome to the ResearchEquals.com wiki!
We are still figuring out the structure, so in order to prevent making too many pages it's going to start out right here until we figure out what pages are needed.
Codespaces are virtual development environments that can be accessed remotely. All secrets (like database URL, API tokens) are stored remotely as well, which means you need to do less setup work. 😊 Moreover, you can access the interactive development environment from your VSCode locally as well as on the browser, meaning you can work in virtually any way you'd like.
We make codespaces available to our maintainers as a perk. To be able to access codespaces after becoming a maintainer, the following things need to be completed:
- Maintainer is a member of the @libscie organization
- Maintainer is granted access privileges to codespaces
Please note the following quirks while using codespaces:
- Your environment times out after 60 minutes of inactivity
- Codespaces are paid for by the hour - we have a spending limit to prevent unhappy accidents
If any questions come up, feel free to discuss this in the Discord channel. Nothing is set in stone, a lot of things have their reasons (see Chesterton's fence), and things change. So if the spending limit needs to be updated, timeouts need to be adjusted, raise it and we can revisit the thing.
We maintain a staged deployment process for quality assurance. You can find a diagram below showcasing the main structure, and more details in each section below (testing - staging - production).
Test deployments are automated with Heroku, and available for each pull request.
Please note all test apps use the same postgres database - which means that a maximum of 22 test apps will function (the maximum default connections to a postgres database).
Auto deployments self-destruct after 48 hours and need to be reactivated by a maintainer if necessary. This is the case because each auto-deployment accrues costs.
The staging branch is automatically deployed to Heroku. Sometimes we may not want to deploy immediately to the production branch and test a set of changes here first.
An example scenario is when we want to do user testing in a safe environment. This is on an ad hoc basis.
The production branch is the main branch.
ResearchEquals is deployed on a continuous basis using Flightcontrol. This is managed in the /flightcontrol.json file (root directory).
There is also an automated deploy of the main branch on Heroku to ensure deployment issues are not a result of either Heroku or Flightcontrol.
There are a bunch of paths in the application. Here we provide an easy to navigate overview. Here we also document any quirks we notice.
Upgrades are important to maintain an up-to-date codebase. This helps us:
- Fix known security issues
- Introduce improvements as we're downstream from a lot of code
- Reduce risk by continuously checking upgrades
Please verify the following checklists if you're upgrading a dependency as provided by dependabot.
Note that dependabot starts rebasing PRs after another upgrade has been merged. It's not the end of the world if you merge while it's doing that, but it is preferred you let the rebase finish. If it's ongoing you'll see the following at the original comment of the pull request:
⚠️ Dependabot is rebasing this PR⚠️
- Do the release notes indicate relevant breaking changes?
- Does the Heroku deploy complete?
- Does the functionality the dependency provides still function as expected?
- Anything off?
- Do the release notes indicate relevant breaking changes?
- Does the Heroku deploy complete?
- Does the functionality the dependency provides still function as expected?
- Anything off?
This also checks for breaking changes as not everybody follows SemVer correctly, where only major versions can have breaking changes.
- Does the dependabot compatibility score provide reason for concern?
- Does the Heroku deploy complete?
- Does the functionality the dependency provides still function as expected?
- Anything off?
As with any piece of software, there are quirks that are important to know but difficult to discover/observe. Below an enumeration of quirks that we have noticed while creating and maintaining this repository:
- Automated deployments on Heroku will send emails with broken links (e.g., verification of account email). This is a result of Heroku deployment apps having a priori not known URLs