有什么建议可以防止用户在构建过程中更新构建ID的git config文件吗？在构建过程中，一些开发团队运行git config --global命令，更改他们应用程序的git config文件设置，或者只是更改值，中断其他团队的构建过程。是否可以锁定该文件或阻止这些命令在Jenkins中运行？我们已经尝试更改文件的权限，但不起作用。感谢您的任何建议。
fumotvh31#
一般来说，构建的最佳实践是使用一次性容器（或者，如果需要的话，VM）来隔离构建。这意味着对构建系统的任何更改都不会持久化，并且任何类型的错误行为都限制在该构建中。修改.gitconfig文件的权限在这里没有帮助，因为当git config修改一个文件时，Git会在旁边写入一个新的临时文件，并在原始文件上重命名。至少在Unix上，所需的权限是对包含该文件的目录具有写权限，而对文件本身的权限是无关紧要的。然而，这可能会带来不便，尽管如此，因为使构建用户的主目录不可写可能会妨碍构建。由于您正确地认为构建不应该相互干扰，并且它们应该只在指定的构建目录中构建，因此在所有构建的构建环境中设置GIT_CONFIG_GLOBAL=/dev/null可能很有用。这会使全局配置为空，并且如果有人试图修改它，它就会失败：
.gitconfig
git config
GIT_CONFIG_GLOBAL=/dev/null
$ GIT_CONFIG_GLOBAL=/dev/null git config --global foo.bar baz error: could not lock config file /dev/null: Permission denied
字符串如果需要创建提交，可以在环境中设置邮箱为EMAIL，名字为GIT_AUTHOR_NAME和GIT_COMMITTER_NAME，然后就可以创建提交了。如果还需要其他配置，您可以将常规文件复制到一个临时文件中，然后在GIT_CONFIG_GLOBAL中使用该临时文件，以便将任何不当行为限制在临时文件中。如果您希望它失败，临时文件，您可以将其放在临时目录中，然后使临时目录为只读（例如，500权限）以使修改失败。我通常会建议你选择其中一个选项，让它非常响亮地失败，以激励团队停止不必要的行为，特别是如果这也影响到开发人员系统。如果我构建的任何工具以任何方式修改了我的Git配置，我会非常生气，因为我已经非常定制了它，我相信至少有一些开发人员有同样的感觉。
EMAIL
GIT_AUTHOR_NAME
GIT_COMMITTER_NAME
GIT_CONFIG_GLOBAL
1条答案
按热度按时间fumotvh31#
一般来说，构建的最佳实践是使用一次性容器（或者，如果需要的话，VM）来隔离构建。这意味着对构建系统的任何更改都不会持久化，并且任何类型的错误行为都限制在该构建中。
修改
.gitconfig文件的权限在这里没有帮助，因为当git config修改一个文件时，Git会在旁边写入一个新的临时文件，并在原始文件上重命名。至少在Unix上，所需的权限是对包含该文件的目录具有写权限，而对文件本身的权限是无关紧要的。然而，这可能会带来不便，尽管如此，因为使构建用户的主目录不可写可能会妨碍构建。由于您正确地认为构建不应该相互干扰，并且它们应该只在指定的构建目录中构建，因此在所有构建的构建环境中设置
GIT_CONFIG_GLOBAL=/dev/null可能很有用。这会使全局配置为空，并且如果有人试图修改它，它就会失败：字符串
如果需要创建提交，可以在环境中设置邮箱为
EMAIL，名字为GIT_AUTHOR_NAME和GIT_COMMITTER_NAME，然后就可以创建提交了。如果还需要其他配置，您可以将常规文件复制到一个临时文件中，然后在GIT_CONFIG_GLOBAL中使用该临时文件，以便将任何不当行为限制在临时文件中。如果您希望它失败，临时文件，您可以将其放在临时目录中，然后使临时目录为只读（例如，500权限）以使修改失败。我通常会建议你选择其中一个选项，让它非常响亮地失败，以激励团队停止不必要的行为，特别是如果这也影响到开发人员系统。如果我构建的任何工具以任何方式修改了我的Git配置，我会非常生气，因为我已经非常定制了它，我相信至少有一些开发人员有同样的感觉。