python_app_version doesn't get set in partial playbook runs

[rlskoeser]

For python apps, we get the python_app_version from the current checkout of the code and use it to determine the path for the deployed version. When we run playbooks without running the full sequence, e.g. using the --start-at-task option, this variable doesn't get set, and then any task that needs to know the path to the deployed version of the project fails.

The task is currently part of the build_project_repo role: https://github.com/Princeton-CDH/cdh-ansible/blob/main/roles/build_project_repo/tasks/main.yml#L43-L54

On a new deploy, it can't be run until the new version of the code has been checked out; but on an existing deploy it could be run anytime.

[acozine]

Interesting challenge. You could try moving the Get python package version task into a pre-tasks section in the playbook - I'm not sure how pre-tasks interact with --start-at-task. If you know the value you need, you could pass it as an extra variable, for example, -e python_app_version=x.x when you run with --start-at-task. I'm not sure what outcome you're most interested in here - running with --start-at-task? handling new deploys? something else?

[rlskoeser]

@acozine thanks so much for looking and commenting. One use case is running --start-at-task and not having to worry about this being unset. I now have a new use case which is why I'm prioritizing fixing this: for the db upgrade I'm doing with Francis, we figured out that we could write a minimal playbook to do the necessary db setup for cdh applications and then update the settings so the application is configured to use the new db. In order to update the settings, I need to know the path for the current deploy - which relies on this python app version (and also on a a git hash from git info, which I figured out when I tried running it). I've got a preliminary solution that pulls these two steps out into a separate task that can be included in the role and included in the new db setup/migration playbook - but that doesn't resolve the --start-at-task use case.

[rlskoeser]

use the current symlink as the default value; update with variables when needed (i.e. full deploy); possibly a next symlink would help with this too