从Jenkins运行mkdir命令时拒绝访问(Access is denied when running mkdir command from Jenkins)

从Jenkins运行mkdir命令时拒绝访问(Access is denied when running mkdir command from Jenkins)

我正在尝试创建一个新目录并将文件复制到它。 所以我正在使用“执行批处理命令”的工作。

首先我尝试运行： robocopy source destination /e 。 然后我试过： mkdir destination 。 在这两种情况下，我都得到了“访问被拒绝”的消息。

如果我自己手动尝试，我可以创建一个目录并将文件复制到它。 目标是远程计算机的共享文件夹：\ computerName \ sharedFolder \

任何人都知道如何获得Jenkins的访问权限？

I am trying to create a new directory and copy files to it. So I'm using a job of "Execute batch command".

First I tried to run: robocopy source destination /e. Then I tried: mkdir destination. In both cases I got an "Access is denied" mssage.

If I try it myself manualy I am able to create a directory and copy files to it. The destination is a remote computer's shared folder: \computerName\sharedFolder\

Anyone knows how to get access rights with Jenkins?

最满意答案

要找到您的工作所在的用户，请在Jenkins中创建一个“scratch”作业。 给它一个“执行Windows批处理命令”构建步骤，并输入“set”作为批处理命令的文本。 如果受影响的作业在Windows从属设备上运行，请确保此作业在同一个从属设备上运行。 运行这项工作。 您的控制台将显示该作业已知的环境变量列表，就像您在桌面上的“命令提示符”窗口中键入“set”一样。 区别在于在底部附近，在您的命令窗口中显示的“USERDOMAIN”和“USERNAME”的用户名将是您（您登录的用户）; 在控制台输出中，它将成为Jenkins作业运行的用户帐户。

该用户可能实际上没有登录权限。 而且，如果Jenkins作为服务运行，您不能只在命令窗口中设置共享：Jenkins作业在不同的Windows“会话”下运行，并且该会话将看不到您在登录会话中创建的共享。

让你超越驼峰的一种不太安全的方法是为你的作业添加用户名（字符串参数）和密码（密码参数）的参数。 在需要访问驱动器之前，无论是在相同的构建步骤还是在构建步骤之前运行的“执行Windows批处理命令”步骤中，运行“@net use：\ computername \ sharename %% / USER：%% /持续性：无”。 （例如：“@ net use p：\ COMPUTER \ SHARE％PASSWORD %% USER％/ persistent：no”）。 “@”将使密码不显示在日志中。 （但是，密码将与作业相关联，如果启用了“允许重建”，则将在Jenkins中进行编码。）确保清理完成后（“网络使用/删除”），您可能需要测试并在尝试连接之前清理驱动器盘符，以防先前的作业失败而未释放盘符。

在这种情况下，您必须为运行作业时可以访问共享的用户输入用户名和密码。 您可以使用预填充的这些值对隐藏参数进行编码，但这意味着用户的用户名和密码将编码到作业定义中，而隐藏密码参数的默认值将不会在Jenkins配置文件中加密。

在Jenkins服务会话中，确实有更安全的方法来启用驱动器共享，但根据您的环境，这可能是'够好'来让您通过您目前遇到的区块。 我在一个我不是Jenkins管理员的环境中使用过这样的技巧，并且Jenkins奴隶的访问权限非常有限（并且没有管理员权限）。

To find out the user under which your jobs run, create a "scratch" job in Jenkins. Give it a single "Execute Windows Batch command" build step and enter "set" as the text of your batch command. If your affected job is running on a Windows slave, make sure this job runs on the same slave. Run the job. Your console will show a list of the environment variables known to that job, the same as if you typed "set" in a Command Prompt window on your desktop. The difference will be that near the bottom, the username shown for "USERDOMAIN" and "USERNAME" in your command window will be you (the user you are logged in as); in the console output, it will be the user account that your Jenkins job runs under.

That user may not actually have login rights. And, if Jenkins is running as a service, you can't just set up a share in your command window: Jenkins jobs run under a different Windows "session" and that session will not see the share you created in your login session.

A not-very-secure way to get you over the hump would be to add parameters to your job for the username (string parameter) and password (password parameter). Before you need access to the drive, either in the same build step or in a 'Execute Windows Batch Command' step that runs prior to that build step, run "@net use : \computername\sharename %% /USER:%% /persistent:no". (for example: "@net use p: \COMPUTER\SHARE %PASSWORD% %USER% /persistent:no"). The "@" will keep the password from showing in the log. (However, the password will be associated with the job and will be encoded in Jenkins if "Allow rebuild" is enabled.) Make sure when you are done you clean up ("net use /delete") and you may need to test and clean up the drive letter before you try to connect, in case a previous job failed without releasing the drive letter.

In this scenario you would have to enter a username and password for someone who can access the share when you run the job. You could encode hidden parameters with these values pre-filled in, but that means that user's username and password are encoded into the job definition, and the default for the hidden password parameter would not be encrypted in the Jenkins config files.

There are definitely more secure ways to get the drive share enabled in the Jenkins service session, but depending on your environment this may be 'good enough' to get you past the block you are faced with right now. I have used tricks like these in an environment where I was not a Jenkins administrator and I had very limited access rights (and no admin rights) on the Jenkins slaves.