SACGF / SACGF/variantgrid

Consider moving upgrader into VG code as app

Open
#1,073 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
30
Forks
3
Avg merge
9h 28m
Merged PRs (30d)
42

Description

Consider moving the upgrade script / migrator into an app - I would say either a new "upgrade" app or potentially move it into "manual"

Advantages would be:

* Could call common code - eg my deployment checks for this task
* Could use eg ```/etc/variantgrid``` configuration to be able to turn off deploy notification on dev machines
* Only take the Django startup hit once

For instance, the following takes 22 secs on my machine:

```
python3 manage.py migrate;python3 manage.py collectstatic_js_reverse;python3 manage.py collectstatic -v 0 --noinput
```

While this takes less than 7 secs:

```
for argv in [["migrate"], ["collectstatic_js_reverse"], ["collectstatic", "-v", "0", "--noinput"]]:
utility = ManagementUtility(["manage.py"] + argv)
utility.execute()
```

James says:

> So the only problem with that is the upgrader also triggers a git pull and then runs the code post git pull.
> But the existing upgrade.sh could easily call git pull, and then invoke an app, and as you say, that would save the "upgrader" from having to startup VariantGrid several times for one deploy.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.