I've been poking around, and I managed to get a project to clone a repo from a GitLab server, and I noticed that everything in
/tmp/vespene/# subdirectories get chmoded to 777.
I also see
/tmp/vespene/#, which is just the project script filled in with template variables. Makes sense.
But does the chmoding mean that a project repo is meant to contain nothing but scripts that are executed by the worker user? I was a bit surprised by this and wondered if it was perhaps not intentional.
I was also a bit surprised to see that install scripts install
requirements.txt globally. I noticed in another thread that you had a hard time keeping up with Ansible's breaking changes. Me too, so I've been using python3-venv and pip-tools to pin Ansible and other dependencies to particular playbooks and roles. I do the same with Django apps. Works pretty well.
python3 -m venv venv . venv/bin/activate pip install --upgrade pip pip-tools pip-sync requirements.txt
I was actually poking around to find out it if made sense to set up Vespene to run an Ansible playbook in a Python venv, but my playbook repo got chmoded to all-executable, and I found that the worker user wasn't able to modify the venv since the repo directory is owned by the vespene user. So I'm pretty sure this all of this means my thoughts are not what you have in mind and all, but I haven't quite figured out what the intention is yet.
Oh, there's an stray "-v" typo in the
git --config core.askPass="bash " line in the git scm plugin. Oddly, I also wasn't able to get the
core.askPass=bash answer_file technique to work at all on the git command line in Ubuntu 18.04, so I just put a deploy token in the git URL. Whatever environment git is running in can't find an answer file no matter where I put it. Can't figure out why not.
Anyhow, thanks for the hard work.