JetBrains / teamcity-deployer-plugin

Deployer plugin for TeamCity CI server
http://confluence.jetbrains.net/display/TW/Deployer+plugin
Apache License 2.0
39 stars 29 forks source link

Use service logon credentials for SMB deployer #67

Open dassie opened 8 years ago

dassie commented 8 years ago

Is there a way to have the SMB deployer use the teamcity service's logon credentials instead of having to enter a username and password in the step? Similar

The problem isn't that it's tedious, it's that it's not really safe to store a password in plaintext.

nskvortsov commented 8 years ago

Hello David,

Currently, there is no such feature. While it sounds like a good feature request, please note, that artifacts are published from TeamCity Build Agent (not TeamCity Server). So you will need to make sure, that each agent on your grid runs under correct credentials.

On Fri, Oct 23, 2015 at 11:23 PM, David N notifications@github.com wrote:

Is there a way to have the SMB deployer use the teamcity service's logon credentials instead of having to enter a username and password in the step? Similar

The problem isn't that it's tedious, it's that it's not really safe to store a password in plaintext.

— Reply to this email directly or view it on GitHub https://github.com/JetBrains/teamcity-deployer-plugin/issues/67.

dassie commented 8 years ago

Yeah, that was my bad. I meant the agent service logon credentials. But you're right, I would need to insure that all agents have access to the file share. My team uses a single account for all the agents and the teamcity service. Not sure how common that is.

I tried to use smb deployer to get rid of some powershell scripts I wrote to upload artifacts. But the user/password text boxes were a deal breaker unfortunately. :(

marcek2-365-bank commented 1 year ago

I also stumbled upon this and could not believe this is how things are setup. Sure there is the requirement that all relevant build agents would have to run under users with sufficient privileges but I believe that would be a far more secure solution. Now I have to (unfortunately) resort back to PowerShell scripts as well. A viable option for sure but not as elegant as having a build step that does the same without the need to run a custom script. Please, consider implementing this feature.