When using the netbox_git: True installation option, the Ansible role will clone the source repo (netbox_git_uri) as user netbox_user. It then goes on to look for a number of commits in the Git history to set various variables used later in the code, e.g. _netbox_git_contains_issue_2239_fix.rc, using (roughly) git log | $commit_id. This is currently done as root.
On newer Git, when git log is called as root in a working tree owned by non-root (e.g. user netbox), it will complain:
fatal: detected dubious ownership in repository at '/srv/netbox/releases/git-repo'
To add an exception for this directory, call:
git config --global --add safe.directory /srv/netbox/releases/git-repo
These error messages are normally hidden from Ansible's output, but the effect is that all checks return a non-zero exit code (due to the pipefail), which causes issues further downstream, such as configuration mistakes based on erroneous assumptions about the state of the NetBox code.
Declaring {{ netbox_git_repo_path }} as a safe directory in user root's Git configuration would be one way to fix this issue. Alternatively, we could run the git log commands as the same router that owns the working tree.
When using the
netbox_git: Trueinstallation option, the Ansible role will clone the source repo (netbox_git_uri) as usernetbox_user. It then goes on to look for a number of commits in the Git history to set various variables used later in the code, e.g._netbox_git_contains_issue_2239_fix.rc, using (roughly)git log | $commit_id. This is currently done as root.On newer Git, when
git logis called asrootin a working tree owned by non-root (e.g. usernetbox), it will complain:These error messages are normally hidden from Ansible's output, but the effect is that all checks return a non-zero exit code (due to the
pipefail), which causes issues further downstream, such as configuration mistakes based on erroneous assumptions about the state of the NetBox code.Declaring
{{ netbox_git_repo_path }}as a safe directory in userroot's Git configuration would be one way to fix this issue. Alternatively, we could run thegit logcommands as the same router that owns the working tree.