vatlab / sos-docs

Documentation of SoS
MIT License
2 stars 11 forks source link

cron job to update docker image #72

Open BoPeng opened 5 years ago

BoPeng commented 5 years ago

@gaow Right now, after a tutorial is updated

  1. If the same user edit the same or another doc soon, he/she will be connected to the same VM and continue what was left off.
  2. Otherwise a fresh VM will be started with the original version of tutorials, which will be out of date.

It is therefore necessary to refresh our VM regularly using a cron job. The script is already available on the server but we should remove the killing existing server part and only update the container.

BoPeng commented 5 years ago

Another option, perhaps safer, is to execute git update in the start script of the container. Then the only corner scenario is two VMs editing the same doc.

gaow commented 5 years ago

But if the PR is not accepted, users will still end up on the original version of tutorials where their previous edit are lost. I'm wondering if there is some optional "login" mechanism where users can choose to browse and edit as "guest" without logging in (current behavior) or log in to edit our documentation. For logged in users we do not destroy their session until after, say, 7 days inactivity.

gaow commented 5 years ago

If we do create this mechanism I think it would be worth to streamline and improve the process and package as a platform tool (also incorporating something like jnbinder to export research websites). I can see it be popular in many scenarios, eg the context of teaching graduate courses while developing them, and in the context of research where small scale collaborations are made easy.

BoPeng commented 5 years ago

But if the PR is not accepted, users will still end up on the original version of tutorials where their previous edit are lost

No, at least I think no.

  1. If the user gets on the same VM (jupyterhub does not shutdown VM as soon as you connect and will liekly connect you to the same instance), what you see is what you left off.
  2. If the user gets on a new VM, the patch I just pushed will run git pull before starting the VM, so the user will see the merged PR. We do need to merge the PRs quickly though.
  3. The missing cases are two instances creating PRs or if PRs are not accepted in time, but there are no good solution to them.