Are there any suggestions for preventing users from updating the git config file of the build id during builds? During builds some develop teams are running the git config --global command and changing the git config file settings for their application or just changing values and breaking the build process for other teams. Is there anyway this file can be locked or prevent those commands from running in Jenkins? We have tried changing the permissions of the file but that did not work.
Thanks for any suggestions.
In general, the best practice for building is to use throwaway containers (or, if necessary, VMs) to isolate builds. This means that any changes to the build system are not persisted, and any sort of misbehaviour is restricted to that build.
Changing the permissions of the .gitconfig file won't help here because when git config modifies a file, Git writes a new, temporary file to the side and the renames over the original file. At least on Unix, the required permissions would be to have write permissions on the directory containing that file, and permissions on the file itself are irrelevant. However, this is probably inconvenient, though, since making the build user's home directory unwriteable will probably impede the build.
Since you are correct that builds should not interfere with each other and they should build only within their designated build directory, it may be useful to set GIT_CONFIG_GLOBAL=/dev/null in the build environment for all builds. This makes the global configuration empty, and it fails if anyone attempts to modify it:
$ GIT_CONFIG_GLOBAL=/dev/null git config --global foo.bar baz
error: could not lock config file /dev/null: Permission denied
If you need to create commits, you can set EMAIL in the environment to the email and GIT_AUTHOR_NAME and GIT_COMMITTER_NAME to the name, and then commits can be created. If you still need other configuration, you can copy the regular file to a temporary file and use that in GIT_CONFIG_GLOBAL instead so that any misbehaviour is limited to the temporary file. If you want it to fail with a temporary file, you can put it in a temporary directory and then make the temporary directory read-only (say, 500 permissions) to make modifications fail.
I would generally recommend that you choose one of the options that makes this fail very loudly to incentivize teams to stop the unwanted behaviour, especially if this affects developer systems as well. I would be very cross if any tool I were building modified my Git configuration in any way, since I've got it very much customized, and I'm sure at least some of your developers feel the same way.