This was first noticed yesterday where a commit to integration/jenkins.git (deployed as `/srv/deployment/integration/slave-scripts` on the integration slaves in labs) caused the modified files to become root read-only after the next puppet run.
@bd808 and myself spent some time debugging this but concluded that the existing puppet manifests didn't appear to contain any code that would cause this.
Relevant puppet manifests:
* [modules/git/manifests/clone.pp](https://github.com/wikimedia/operations-puppet/blob/3b4526cc803356907f2c7ca49ddae00266f2cbdc/modules/git/manifests/clone.pp)
* [modules/contint/manifests/slave-scripts.pp](https://github.com/wikimedia/operations-puppet/blob/3b4526cc803356907f2c7ca49ddae00266f2cbdc/modules/contint/manifests/slave-scripts.pp)
I confirmed it to be deterministic, when debugging on one of the slaves, by running `git reset --hard HEAD^` and fixing permissions on the existing files. After we ran the puppet agent again, we observed the same issue happening again. The modified files since the previous commit were now all formatted as `-rwx------ 1 root root`.
In attempt to confirm there wasn't any preexisting state with sticky bits or umasks, I depoled one of the slaves, rm -rf'ed the slave-scripts checkout and had puppet re-create it. It looked okay at first. The files were properly readable by the Jenkins user and other users.
However after making another commit (e.g. [I4d94af4673](https://gerrit.wikimedia.org/r/#/c/187320/)), the same issue happened again:
integration-slave1007:
```
$ ll /srv/deployment/integration/slave-scripts/bin
-rwxr-xr-x 1 root root 1.1K Jan 28 23:21 mw-run-update-script.sh*
-rwxr-xr-x 1 root root 682 Jan 28 23:21 mw-send-to-coveralls.sh*
-rwx------ 1 root root 158 Jan 29 02:39 mw-set-env-qunit.sh* <--
-rwxr-xr-x 1 root root 1.1K Jan 28 23:21 mw-set-env.sh*
```