I'm running the maven release plugin (org.apache.maven.plugins:maven-release-plugin:2.3.2) and noticed that the password to the scm is saved in clear text in the release.properties file when passed in via the command line. I want to know if there is a way to turn this off.
I'm using Hudson to automate the release process, and the svn username and password are passed in to the command line via Hudson. The reason for this is that the person doing the release preparation can change and I have multiple hudson jobs sharing a settings.xml to release different projects.
I'm passing in parameters such as:
-Dtag=${svn.label} -DreleaseVersion=${maven.releaseVersion} -DdevelopmentVersion=${maven.developmentVersion} -Dusername=${svn.username} -Dpassword=${svn.password} -DscmCommentPrefix='[maven-release-plugin] ${env.BUILD_URL} '
The release.properties file gets created during the release:prepare, but I don't think it should be necessary as I'm passing in all the information along the command line. When this release.properties file is created it includes the password in plain text. This is problematic because it's possible to use hudson to browse the workspace, so anyone with access to hudson can see the password by opening the file via the browser.
Is there a way to not create the release.properties file, or to not save the password in the file? I realize that an encrypted password could be saved in a settings.xml file but this file is shared among multiple jobs and is not editable by the people running the jobs.
We avoided such problems letting the svn-client caching the password for us.
For this purpose we have a special account with adequate rights in subversion.
On our build server the password is stored plain text by the svn-client in the account for the user who runs hudson. For us it's no problem because only to hudson administrators have access to this account.
But you can also configure the svn-client to store the password encrypted. The configuration depends on your operating system.
svn-client configuration is stored in .subversion (linux) or "ApplicationData/Subversion" (windows).
See
here, here or here.
Just a couple of days ago somebody asked for this improvement: https://jira.codehaus.org/browse/MRELEASE-846
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I am trying to rebuild the metadata for a particular artifact in Nexus. I want to use the REST API:
DELETE /service/local/metadata/repositories/myRepository/content
So far it is working well. However, I need the Nexus Administrator Role for the command to work. Since I am building in a large environment with lots of users using Ant (which is automated by Jenkins) I would love to use another user, possibly just dedicated to refreshing the metadata, with only the required privileges (but it seems like that privilege is admin). I don't want my build.xml to have admin credentials!
I am thinking of some workarounds such as calling a separate Jenkins job with hidden credentials, or add a post-build step in the build job... It all just sounds too ugly.
Any thoughts or suggestions?
Thanks
Phil
They need the "Rebuild Maven Metadata" privilege.
You can use Mask+Passwords+Plugin to hide the passwords in the job, and pass it as a parameter to your ant script.
When configuring a build job for the first time that uses Subversion for SCM you get an error that looks like this:
I'm aware that to enter my credentials I simply need to use this url.
http://< my-server >/scm/SubversionSCM/enterCredential
But I'm trying to completely automate the set up/configuration of my jenkins server. Is there a way to give jenkins svn credentials without having to access the UI?
My jenkins server is on Windows and is the latest version. Subversion is on linux.
Edit: I've come across a screenshot online similar to the one above except the is a Credentials field! Does anyone know why I can't see this field. Here is the url of the image
http://michal.karzynski.pl/images/illustrations/2014-04-19/jenkins-source-code-management-configuration.png
Thanks
https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
this can provide credentials to svn repo.
what actually you gonna do? just access the SVN or looking for the SVN SCM change or any other. simply enter password i don't forsee a need of jenkins plugin
The solution is to create some "domain credentials" in the "Manage credentials" section (admin part: http://<server>:8080/credentials/):
One way around this is to use the Subversion command line. Jenkins doesn't need the command line client and you might have to install it.
However, for a particular repository, do a checkout of a project via the command line with the user you want to use. Then, say "Yes" when Subversion asks if you want to cache the credentials.
When Jenkins does a checkout, it will use these cached credentials if you didn't specify a particular Jenkins credential to use. This works per Subversion repository.
We currently use TeamCity to build a deployment artifact, then a further TeamCity task takes that artifact and deploys it to our development and testing servers on demand.
We can store the passwords and other secret data in properties files that we can check into source control, as these are all internal servers and the developers have full access to them.
However for release to Production (and our final test layer) there are secret passwords and configuration that we don't want checked into the normal source control, or to have development be able to discover the passwords. So to do 'real' deployments we have to hand the artifact over to another team and they maintain a properties file with the production values.
What methods exist to store these secrets and allow TeamCity to run a deploy without ever leaking the secrets out?
(note I am one of the devs and it is not a trust issue... I don't want to have the ability to find out prod passwords so I can never accidently know them and do some horrific damage!)
Probably what you need here, is to create a separate project with narrower scope of permissions (for example, allow only certain people to edit build configurations). In this project create a build configuration, responsible for deployment. In this configuration, you can define a Typed Parameter of type 'password' to store the password to the production environment.
Another option is to use Deployer Plugin, especially its ability to deploy over ssh with private key authentication
If you are OK to use a third party solution, consider using a solution like CloudMunch which can help you to perform release management functions with these secure parameters collected at deploy time and encrypted post deployment.
Disclaimer: I work with CloudMunch
You can do 2 things.
Use a teamcity project to deploy artefacts for production only. This will only be accessible to ops members.
Teamcity also supports running agents with different user ids. You can create a new user id which can have access to the production "secrets" (passwords and configuration). Use this id to run the targets in the 1st step.
I have two repositories in xp-dev with different user name and password, and i have configured TortoiseSVN svn url with the one repository, and i have folder in my file system, i am doing commit and update.
Now, i want a another folder to use other repository location, So how to have two folders synchronized with the two repositories in TortoiseSVN.
Just checkout second URL with corresponding username and password and verify results. If first user have not rights in second repo, you can even don't supply this information on start - you'll get request (after failed login)
I can't see any traces of problem exploration in your question. What you done? What was bad?
PS: Under ...\Application Data\Subversion\auth any amount of separate credentials can be stored (and stored really)
PPS: you can read about servers file and it's features and use, if you want