My company has a particular way of working, with an existing CI system, and I'd like to find a way of moving to TeamCity. I've run into a problem with permissions though.
In our current system, a group of developers might be assigned to project A. They can add/modify/remove continuous integration tasks that are related to (are children of) project A, but they can't delete project A itself.
I've got a test install of TeamCity 10, set up with per-project permissions. Project A is a top-level project. There's a projA group, which assigns a dev guy role with scope limited to Project A. user A is a member of the projA group.
Whatever permissions I choose for the dev guy role, it seems to have one of two outcomes, neither of which is useful:
user A can't delete Project A, but can't create or modify build configurations.
user A can create and modify build configurations, but can also delete Project A.
It looks like Edit project is the relevant permission, but it's not granular enough -- it includes some abilities I don't want along with the ones I do.
Is there a way around this?
Related
So, I have owner privileges on some group in Gitlab (not privately hosted instance), and there is a registered runner that I want to assign to a new project in order to use it for CD (It is in use on other projects I am an owner at). However, I don't see it in CI/CD runners settings even though it is not locked for one project. I was also trying this https://docs.gitlab.com/ee/api/runners.html#enable-a-runner-in-project solution (API call) Gitlab provides but it seems like the runner does not exist (generic error, it says the page does not exist or I have no permission).
I thought it might be a permissions problem but it doesn't make sense (or does it?) because I have owner privileges. In docs they say:
"If you are Master on a project where a specific Runner is assigned to, and the Runner is not locked only to that project, you can enable the Runner also on any other project where you have Master permissions.
To enable/disable a Runner in your project:
Visit your project's Settings > CI/CD
Find the Runner you wish to enable/disable
Click Enable for this project or Disable for this project"
and well, I can't find it. Does it sound like a bug/mistake on docs or my lack of knowledge? And if it is my lack of knowledge, do you have any ideas for possible solutions?
TL;DR:
It seems like some kind of group permissions bug.
A possible workaround is to create another user and invite him to a project that uses that specific runner, as master (not owner), and then invite him to the project you want to assign that specific runner to. then, you will have that runner available under specific runners.
Ok, it seems to be a problem with gitlab/gitlab-runner permissions, or just a rather strange behavior. This is what someone wrote in the issues section of the project ( https://gitlab.com/gitlab-org/gitlab-runner/issues/1322 ):
"Consider the following setup:
user_A is owner of project_1, runner_R is registered with project_1's token
user_A is owner of project_2
--> runner_R is NOT visible to user_A from project_2
user_A is promoted master of project_1
--> runner_R is now visible to user_A from project_2
hence my conclusions:
i don't need to be master of a project to select a runner from a project i own, being an owner works too
being a project owner is not sufficient for a project's runner to be visible to me from another project, i need to be master of the project where the runner was registered"
I hope it might be helpful to someone facing the same problem as me.
As you can see in the picture I have project administrator permission and I added some projects to Project Administrators group.
Today I created 2 new projects. And VSTS groups stuck to Custom group.
I don't know why I have a new group which is called Custom even I don't have it in Security/Groups.
I can't change Custom to Project Administrators and for other users to Contributor.
After all, I created a Test project and I didn't get any issues.
How can I fix the problem? Thanks
Custom simply means you're a member of one or more groups that are not in the list of:
Project Administrators
Project Contributors
Project Readers
The project's Default Team
For example, you're a member of a Team (Teams are represented as a security group). Or you're a member of any custom created group within the project. These custom groups are not shown in the Manage projects dialogue.
I do not see the behaviour of not being able to change the values, the only reason I can think of is that your user doesn't have permissions to manage permissions in those projects. Have you tried changing the security directly through the project's own Security tab?
When a private agent build starts in VSTS, it gets assigned a directory, e.g. C:\vstsagent_work\1\s
Is there a way to set this to a different path? On other CI servers, like Jenkins, I can define a custom workspace for a job. I'm dealing with a huge monorepo and have dozens of build definitions around the same repository. It makes sense (to me anyway) to share a single directory on the build agent computer.
The benefit to me is that my builds can use pre-built components from upstream repositories, if they have already been built.
Thanks for any help
VSTS build always creates a working directory per build definition. This leaves you two options:
Create a single build definition and use conditionals on steps to skip certain steps in order to only run what is needed. This allows you to use the standard steps and may require a powershell script to figure out which steps to run and which ones to skip. Set variables from powershell using the special logging commands.
Disable the get sources step and add a step that manually fetches sources. You'll need to clean the working directory, checkout the right commit, basically replicating the actions in the get sources step manually. It may require some fidgeting to get all the behavior correctly for normal build, pull request builds etc. That way you can take full control over the location where sources are checked out.
I'd also recommend you investigate the 2017 project formats that use the new <packageReference> in the project files to fetch packages. The new system supports configuring a version range which can always fetch the latest available version of packages. It's a better long-term solution.
No, it isn’t available in VSTS build system.
You can change working directory of agent (C:\vstsagent_work) (Re-configure it and specify another working folder), but it won’t uses the same source folder for different build definitions, the folder would be 1, 2, 3 ….
I have a lot of projects in my TeamCity server, for building and testing multiple sites. We use Selenium RC to test the sites every night, and I would like to reuse one step or configuration instead of having copies in each project.
I have looked into using Templates, but they only seem to be accessible from the project it is defined in. The same goes for properties, as I tried to put paths and some shared values in system or environment properties and using copied build steps using those shared properties.
But it all fails, as none of these methods seem to be usable across projects. How do you solve this type of issue? It must be possible somehow, right?
As per my comments for your question you can use a single template configuration build across multiple Projects.
See TeamCity documention for information on how to do this.
TeamCity has a new feature (as of 8.0) that supports global configs/parameters/env variables. 8.0 supports the new concept of project organization/nesting, and as part of that feature set all projects now inhert from the "Root" project. And on that root project you can specify a number of things, including parameters, etc. This does not appear to support build steps.
They documented the change in http://youtrack.jetbrains.com/issue/TW-11202.
--
You could achieve a "global property" by creating a dummy build configuration which has your shared properties then for all your builds which need access to the global properties you create a build dependency. When your real build configuration is called it will first call the dependent build configuration (which does nothing meaningful) then it passes the properties from the dependent config (with a dep.bt prefix instead of just the system prefix).
Depending on the logic you need in a shared build step you may be able to actually perform real logic in the dependent build (it won't be able to inherit any properties or VCS details from the "real" build).
Since this is a bit outdated, and the answers above aren't completely clear, thought I would post how I did this with TeamCity 8+.
Basically, a template can be used within the project and its children. If you move a template to the parent, it becomes available to all the siblings of the original project.
Go to the template.
Click the "Move" button (bottom-right pane).
Select a parent (or root).
Note: If the template is attached to a VCS root that is bound to the current project, you'll first have to move the VCS root to the same level to which you're trying to move the template.
Let's say I have two "projects" within TeamCity, which are two websites, that each use a shared library that isn't within the svn path of the website. Here is the svn structure to make it more clear:
Website A: svn://root/web/websitea (uses shared library a)
Website B: svn://root/web/websiteb (uses shared library b)
Shared Library A: svn://root/shared/liba
Shared Library B: svn://root/shared/libb
How would I setup a teamcity project for website a? Right now I have it point to the svn://root but that would make it trigger a build even if website b or shared library b was changed, which is not right. What I really need is a way for it to trigger a build only if there is a change in svn://root/web/websitea OR in svn://root/shared/liba.
I tried setting up two vcs roots within the same project which point to the two svn paths above, however there doesn't seem to be a way to set a working directory for each vcs root. For this reason, it ended up just copying the contents of the two svn paths directly into the root of my build directory instead of putting them in the proper places (C:\Build\Web\WebsiteA & C:\Build\Shared\LibA).
TeamCity's checkout rules functionality is able to support the setup you're describing. My team uses it to do something similar to what you're trying to do.
First, set up a single SVN Root. The URL of this root would be something like this:
svn://root/
Then set up the following checkout rules.
For Project A:
+:web/websitea=>/web/websitea
+:shared/liba=>/shared/liba
For Project B:
+:web/websiteb=>/web/websiteb
+:shared/libb=>/shared/libb
The TeamCity documentation on checkout rules isn't totally clear about this point, but only the particular paths you have included will be used to trigger builds. This should meet your need to have only changes is websitea and liba trigger its build (and the same for B).
In addition to what Eric mentioned, if you need the entire source root to be checked out, but only trigger the build based on particular paths, you can edit the VCS Trigger rules in the Build Triggering section to have something like:
+:web/websitea
+:share/liba