I'm trying to create a custom pre-checkin policy in TFS. I was able to create it according to my needs. Now I have a problem. I'm required to have that policy executed on selected computers that are client to that TFS collection.
Whenever I add the custom policy to the collection, it is applied for every computer that is client to that collection - irrespective of the fact whether the custom policy is registered on the client computers or not. For those computers that do not have the policy DLLs registered, their check-in fails no matter what.
My question is, how can I have my policy enabled on my TFS collection and have it run on selected TFS clients?
You can't. If you have a check-in policy, that policy is applied to all check-ins that occur via Visual Studio, regardless of user. There is no way to change this behavior. This is one of many reasons why you should not rely on custom check-in policies.
Git has support for much more robust branch policies, and Git has been where Microsoft has been investing their effort for the past several years, as Git has (like it or not) become the industry standard for source control.
Check-in policies are a set of rules (each policy as a single rule) that must be followed whenever a developer wants to check-in changes to a repository.
Each policy that is previously set for the specific Team Foundation Server project requires a developer to take specific action prior to checking in changes.
Unlike some other requirements such as a gated check-in, it's also not able to directly bypass for some users.
As any alternative way to achieve this, you could refer solutions in this similar question: Restricting TFS check-in policy to specific users
Custom policy implementation. It allows to run child policy if user
does not have certain permissions (is not member of certain group).
It can be used with custom path policy from TFS power pack and
ColinsALMCornerCheckinPolicies Then it will be possible to ask for
code review only for certain projects|files|folders and only if user
has no permission to check-in without code review.
You need to create customize check in policy and child policy, inspect the Custom path Policy to make it work.
Related
Is there a way to share Jenkins service endpoint credentials across multiple TFS projects? We have close to 30 projects, and each build requires us to configure the same set of credentials.
I would like to set an environment variable or something that would allow us to manage those credentials in one place for all TFS projects.
For a specific project, you click the gear here:
And then enter the credentials here:
This is not possible yet, there is a Feature Request about it, you can up vote there.
To automate the process you can create the Jenkins endpoints with the Rest API Endpoints - Create.
No. Service connections are scoped at the Team Project level. Team Projects are intended to be largely isolated from one another, so there is limited ability to share things between them. If you need to manage a service endpoint across many projects, you'll need to look at the REST APIs and write a programmatic solution.
I have developed a TFS web extension. I have some auxiliary data that I've placed on a separate page, which is currently accessed from a hub. I want to restrict access to that data so that it can only be changed by people with certain permissions (e.g. only people who have the "Manage project properties" set to Allow).
Both hubs were created by following these instructions, but it doesn't seem to mention how to restrict access to the hub.
According to this, I can't restrict access to a hub group, and it sounds like this may also apply to a hub.
Is it possible to hide the hub based on the user's permissions? If not, what are my options for restricting access to the auxiliary data?
Yes, this is also apply to a hub. At the code level, as a extension author, you could not limit your extensions' access to specific users or groups.
For now, there is also no way to specify the users or groups to access the installed extension in web portal or server side (expect the priced).
There has been a related user voice, you could vote and follow up, TFS PM will kindly review the suggestion.
VSTS extension restrict for specified users or groups
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/32926549-vsts-extension-restrict-for-specified-users-or-gro
One way maybe work: if a user doesn't have access to the various data that the extension pulls from TFS/VSTS, they will have parts of this extension not work. However, you could not hide the extension and its link entirely for a user by now.
I have two projects in JIRA: software project and service desk project.
My goal it to enable my service desk customers to access the software project but in a limited way. E.g.:
clients could create stories,
comment on them,
assign priorities
and assist with assigning them to iterations / releases.
But they would not be able to perform and see some actions e.g.:
see the logged time
and ideally to keep some of the ticket / story fields and comments as internal use only so I can have technical discussions with my team without the client seeing them etc.
I can see in documentation that "Service Desk Customers can't log in to JIRA applications":
https://confluence.atlassian.com/servicedeskcloud/setting-up-service-desk-users-732528877.html
But is there any workaround to give Service Desk Customers access to JIRA applications? Is there any simpler method than making a REST API bind? If yes, then how it could be achieved?
The documentation is not clear. Add their accounts to the jira-users group and they will be able to log into JIRA as regular users. The point is that member of jira-users consumes a JIRA user license, while "pure" customer account does not.
As regular regular users they will have permissions just as you configure your project Permission Scheme, so everything is in your hands. Using roles you can restrict issue comments to those roles. There's also nice Comment Security Default plugin to use with that.
We're using Jenkins (and precisely Cloudbees) for couple years. Well, it works.
Not I have new use case when I would like to allow trigger build remotely (w/o user account in Cloudbees).
Looks like it's impossible (standard token trigger mechanism requires an account in Cloudbees).
The only one way that I see it to set-up instant message integration (e.g. Jabber) and trigger builds in chat. It's nice solution that I would like to have, but ... it doesn't work for me. No errors and no messages (I tried different jabber servers).
Because I have only one such weird user I don't want to install special software (like Jabber/IRC server) and wanna use existing (like Gtalk or similar).
Any thoughts will be welcome.
standard token trigger mechanism requires an account in Cloudbees
You can use the Build Token Root plugin to bypass authentication long enough to check the token.
In the long term it would be desirable for Jenkins to let users create non-user principals that would have their own API tokens and SSH keys (but no UI login) and a restricted subset of permissions, so you could freely create a one-off principal for a specific purpose such as triggering builds. The infrastructure for such a feature does not exist today, however.
I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.