我们使用（我们本地的）GitLab并在工作分支上完成了所有工作。将为这些请求创建合并请求，并在批准后将它们合并。
对于每个此类合并，我们需要做一些“内务处理”。这涉及存储/更新一些需要此整理的文件。具体来说，这将更新各种（定制的）代码质量检查的基准，以便在合并请求管道中运行这些检查时，可以识别出新问题并将其报告为讨论内容。
此状态是不可避免的，必须存储在某个位置。是的，我们了解Sonar，但是由于与该问题无关的原因而造成麻烦，并且我们不打算使用它（它不太适合我们的流程）。是的，从技术上讲，我们可以尝试将基准存储在单独的服务器上，但是当存储库应该能够执行此操作时，这对于所有相关人员来说似乎都是不必要的麻烦。
问题是，如何在GitLab合并过程中更新这些基准文件？ （我们不允许开发人员向基准文件提交更新）
我已经从配置项工作中尝试过此操作。当作业在正确的时间运行时，我们很难让“用户”“推送”这些更新。该作业将设置身份，SSH密钥以及所有其他内容，因为它通常处于分离状态，因此必须签出/拉出分支，更新文件，暂存它们，提交它们，但是推送仍然失败，并显示“权限被拒绝，请重试。 ”。即使工作确实可行，工作还是有可能与其他合并错误地交错。
理想情况下，我们希望序列化合并并“修改”合并以包括基准更新。我在GitLab的/ hooks（即不仅是/.git/hooks）文件夹中找到了一些关于重新调整钩子的注释，但是我放置的测试脚本无法执行任何操作-我为每个钩子创建了一个钩子，并且它们看起来都差不多：
#!/bin/sh
echo Running a ______ hook!
echo "_______ from $USER@`hostname`" >> hooks.log || echo "hooks log write failed."
git add hooks.log || echo "git add failed."
与GitLab进行交互的“正确”方法是什么？
谢谢！
更新：我设法使CI作业在合并一次之后创建了另一个提交。由于多种原因，我一开始无法执行此操作，包括以下事实：它以分离的头部状态运行，git忽略了SSH凭据并使用了环境变量中的令牌，而先前的运行确实创建了保留在本地的提交（但（不推）甚至是错字。但是，正如我已经指出的那样，这并不能真正解决问题。
作为参考，该工作目前正在做什么：
git fetch origin
git reset --hard origin/$CI_COMMIT_REF_NAME
<perform modifications>
git add <what-to-add>
git config --local user.email "...@..."
git config --local user.name "..."
git commit -m "... [skip ci]" && (git push https://$AUTO_COMMIT_USER:$AUTO_COMMIT_TOKEN@.../${CI_PROJECT_PATH}.git/ $CI_COMMIT_REF_NAME) || (echo "No changes made")