Skip to content

Validation and deployment of pull requests

Obada Haddad edited this page Jan 17, 2025 · 16 revisions

Validation and deployment of pull requests

The main steps are:

1. Local testing and validation of the changes

Setup

Required:

  • "Maintain" role on the repository
  • A working local installation

Pull the changes, checkout the branch you are testing and deploy your local instance:

cd codabench
git pull
git checkout branch
docker compose up -d

If necessary, migrate and collect static files (see https://github.com/codalab/codabench/wiki/Codabench-Installation).

💡 Remark: if the branch with the changes is from an external repository, you can create a branch in Codabench's repository and make a first merging into this new branch. Then, you'll be able to merge the new branch into master. This way, the automatic tests will be triggered. EDIT: It may be possible to trigger the tests even if the branch is external. To be confirmed.

Testing

Here is the usual checklist in order to validate the pull request:

Capture d’écran 2023-12-07 à 16 48 32

The contributor may have provided guidelines for testing that you should follow. In addition to this:

  • Testing must be thorough, really trying to break the new changes. Try as many use cases as possible. Do not trust the contributor.
  • In addition to the checklist of the PR, you can follow this checklist to check that the basic functionalities of the platform are still working: manual validation

Merging

Once everything is validated, merge the pull request. If there are many minor commits, use "squash and merge" to merge them into one.

Capture d’écran 2023-12-07 à 16 57 16

You can then safely click on Delete branch. It is a good practice to keep the project clean.

2. Update the test server

Here are the necessary steps to update the Codabench server to reflect the last changes. We prodive here general guidelines that work for both the test server and the production server.

Log into the server

ssh codabench-server
cd /home/codalab/codabench

Replace codabench-server by your own SSH host setting, or the IP address of the server.

Optional: use codalab user account

sudo su codalab

Pull the last change

On the test server always stay on develop branch. On the production server, always stay on master branch.

docker compose down
git status
git pull
docker compose up -d

Restart Django

docker compose stop django
docker compose rm django
docker compose create django
docker compose start django

If docker compose does not exist, use docker-compose.

Database migration

docker compose exec django ./manage.py migrate

Do not use makemigrations. Remark: we need to solve the migration files configuration. In the meantime, makemigrations --merge may be needed.

Collect static files

docker compose exec django ./manage.py collectstatic --noinput

Final testing

  • Access the platform from your browser
  • You may need a hard refresh (Maj + R) so the changes take effect.
  • Check that everything is working fine, the new changes, and the basic functionalities of the platform

3. Merge develop into master

Once some pull requests (~3 - 10) were merged into develop, we can prepare a merge into master. Simply create a new pull request from Github interface, selecting master as the base branch:

Capture d’écran 2023-12-07 à 16 45 53

In the text of the PR, link all relevant PR made to develop, and indicate the URL of the test server. Example: https://github.com/codalab/codabench/pull/1166

4. Update the production server

Same procedure as 2. Update the test server, but on the production server.

Do not forget to access the platform and perform a final round of live testing after the deployment.

5. Creating a Release

Once the develop branch has been merged into master, it is possible to use the Github interface to tag the commit of the merge and create a release containing all the changes as well as manual interventions if needed.

For this, you will need to go to the release page and click on Draft a new release image

Afterwards, you click on Choose a tag and enter the tag you want to create (in this exemple, 1.17.0 which doesn't exist yet) image

You can then choose the targeted branch to create the tag on (master in our case) and then click on Generate release notes Github will automatically generate releases based on the new commits compared to the last tag.

image

You can then change the text format however you like, as well as add things like Manual Intervention if there are any.

When you are done, you publish the release.

image

TODO

Add a note about:

  • Merging the github action PR to update the release tag
Clone this wiki locally