Fix git permission issue in CI build

[jnidzwetzki]

The new permissions checks to fix CVE-2022-29187 in Git caused some issues in our CI pipeline. This patch adds the checkout directory to Git's "safe.directory" setting.

Failed CI run: https://github.com/timescale/timescaledb/actions/runs/3690974658/jobs/6248545042

[codecov]

Codecov Report

Merging #5089 (1593e4f) into main (558688c) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #5089   +/-   ##
=======================================
  Coverage   89.60%   89.61%           
=======================================
  Files         227      227           
  Lines       51620    51619    -1     
=======================================
+ Hits        46253    46256    +3     
+ Misses       5367     5363    -4     

Impacted Files	Coverage Δ
src/loader/bgw_message_queue.c	86.36% <0.00%> (-2.85%)	⬇️
tsl/src/nodes/data_node_dispatch.c	93.03% <0.00%> (-0.22%)	⬇️
tsl/src/bgw_policy/job.c	88.31% <0.00%> (-0.05%)	⬇️
src/bgw/job.c	93.12% <0.00%> (+0.16%)	⬆️
src/bgw/scheduler.c	86.18% <0.00%> (+2.30%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 558688c...1593e4f. Read the comment docs.

[svenklemm]

I think the better approach here is to make git skip that check by adjusting the configuration as we do in other places. E.g. 17844a4087

[jnidzwetzki]

I am in favor of fixing the permission problem than disabling the new Git security checks. In this specific case, we have a mismatch between the owner of the checkout directory and the checkout. Is there any technical problem with this solution?

You mentioned in Slack, that the user is controlled by the GitHub runner. This is true, but if GitHub decides to let the workflow run as another user as root, a lot of things (e.g., apt-get) would also break. I could not find a specification for it. But I don't suspect that this will change unannounced.

[svenklemm]

I am in favor of fixing the permission problem than disabling the new Git security checks. In this specific case, we have a mismatch between the owner of the checkout directory and the checkout. Is there any technical problem with this solution?

You mentioned in Slack, that the user is controlled by the GitHub runner. This is true, but if GitHub decides to let the workflow run as another user as root, a lot of things (e.g., apt-get) would also break. I could not find a specification for it. But I don't suspect that this will change unannounced.

Running a recursive chown is several orders of magnitude slower than adjusting the git config and this does not account for the additional runtime of the check itself. The suggested solution with chown only works for that specific user and prevents sharing the checkout between multiple steps when the checkout directory is bind mounted into docker containers as we do in some of the other workflows.

[jnidzwetzki]

@svenklemm Changed, let's do in that way.