auto-update for client code

[gonzalomerino]

It will be good if the client code has auto-update capability, so that the version deployed at remote sites can be controlled up to some extent centrally, without the need for remote sites to take action.

[briedel]

Could we have client.py do a git pull after it is done?

[dsschult]

Maybe once we move to a model where master is always stable. That requires discipline and adherence to a git branching model from me. It would also be nice to have tests to say "this is stable code and can be merged into master".

[jvansanten]

Even given a stable master, the main obstacle I see is that git pull is not guaranteed to succeed without supervision. There are a couple of ways it can fail:

1. The local user may not have WIPACRepo/pyglidein directly configured as a remote, or may be using password authentication (easy fix: parse the output of git remote -v and git remote add upstream https://github.com/WIPACrepo/pyglidein.git if it's missing)
2. The local user may have a dirty working copy. We could just always do a git stash followed by git pull upstream master --commit, but this still has the potential to step all over work in progress.

Another way to synchronize things would be to create a tag when new features should go live, and have the server include the current tag in the state it sends to clients, and have them check out that tag if it doesn't match what they currently have.

[dsschult]

I have debated tagging releases, so there are "known good" points to auto-update to. I already have code that knows how to find the latest release from github, which could be incorporated.

But yeah, not sure basing everything on git pull is the best idea. Might be better to change our deployment strategy for non-dev situations.

[gonzalomerino]

Are python eggs or containers acceptable?

[dsschult]

python egg = pip install

[dsschult]

Discuss this at the collaboration meeting in the Grid Ops session.