Tom Clifton

After going through support with Carlos and the plastic team we were able to get to the bottom of this so thought it would be worth posting the issue and solution for anyone else who comes across this. The main issue was that this just was not working with the cloud version of plastic that we were using on MacOS and we had to switch to the Enterprise version instead. I then had to run `clconfigureclient` in the terminal and follow the prompts to get plastic configured correctly for the LDAP working mode. After that the client.conf file needs to be copied from ~/Library/.plastic4 to the plastic scm binary folder. I also had to copy tokens.conf and cloudregions.conf from that folder to the same binaries folder as well (its possible other conf files might need copying there too but that did the job for me). The binaries folder where we copy these conf files to is also different between plastic 10 that we are using and older versions. On plastic 10 it is: /Applications/PlasticSCM.app/Contents/Applications/cm.app/Contents/MacOS/ And on older versions of plastic it is the path mentioned above: /Applications/PlasticSCM.app/Contents/MonoBundle/ Following these steps got the shell command working when run under sudo and team city started working with plastic again after that.

Hi Rafael, Thanks for the quick response. So the issue was related to the server permissions - I modified the permissions for the repo (which is the screenshot i showed above) but didn't realise that the server itself also needed permissions set. For anyone else curious that was the second permissions option in the context menu for the repo. Once I set that up it all worked fine for the other team members. Thanks! Tom

Hi, We are running in to some issues when setting up client-side triggers for repos on the plastic cloud server. As an admin I am able to run the following command: cm trigger create after-setselector "after-set-selector-trigger" "C:\Scripts\AfterSetSelector.bat" --server=Company@cloud and that sets up a client side trigger just fine that works as expected. However, when other members of the team who are not admins attempt to create the same trigger they receive the following error: You don't have permissions for operation mktrigger. We have the permissions set up as below. The selected permissions is the group for the team members and I have attempted to override the mktrigger permission as well as leaving on the default (which has allowed ticked anyway). Is there something that I am missing for the configuration setup? The above looks to me like it should be set up correctly. I haven't found any other relevant settings on the cloud dashboard that look like they would allow me to do this. Thanks, Tom

I've submitted a support ticket as suggested. Thanks, Tom

Hi Carlos, You were right about the permissions being incorrect but I'm still not having any luck unfortunately. I adjusted the owner to root which is the owner that the rest of the files in the MonoBundle folder have as well as the user that TeamCity runs under. I tried a few different permissions (chmod 644 to start as that seemed to be what most of the rest used) but couldn't get it to work even setting chmod to 777. Here are the files in the MonoBundle folder showing permissions: + And here is the result in the terminal. As you can see running the shell normally the commands work but under sudo it just hangs there. I have tried restarting the terminal and machine after making these changes but not having any success at all. I have also tried this on 2 macs. My other mac is using a slightly older version of plastic scm (9) but this does not work for either. I also tried adding the log conf file as noted in this post which generated a log file with the older version of plastic SCM but not the latest 10.0 version. Interestingly the newer version does not have the cm.exe file in the MonoBundle folder so don't know if that is a factor there or not. The log file did not show anything useful anyway though so I have ignored that part. I'm not sure whether any of that information helps to narrow down what's going on. If not then I can certainly open a support ticket but at the moment the provided instructions seem incorrect as far as I can determine. Thanks, Tom

Hi, Is there any update on this? This basically means that we can't use Team City on Mac with Plastic which is a big issue for us. As stated above the config file is located in the above specified location but we still can't perform and shell commands as sudo. Is there something else I should be looking at? Any help would be greatly appreciated. Thanks Tom

Hi Carlos, So i did also try that as it was suggested on the linked forum posts and have double checked that (and tried restarting the machine) and it is still not working. As mentioned running `cm shell` and then plastic commands works fine but running `sudo cm shell` results in nothing happening which I assume is the issue that Team City is happening. Could you please advise me on what else I could try or let me know any relevant logs to attach. Thanks, Tom

Hi, I've been struggling getting PlasticSCM working with Team City and was hoping to get some help resolving the issues I am seeing. Team City is running on MacOS. I have attempted to follow this guide for integrating the plugin but the plugin file location is only specified for PC and no equivalent seems to exist for Mac so I have uploaded the plugin from the location on my PC. I am unable to get past the step of setting up the VCS root on Team City. After filling in the information and clicking either Create or Test Connection the UI gets stuck on a spinning circle. Looking at the Team City server logs I can see the following error: I have found some similar forum threads here, here and with Jenkins here but unfortunately none of these has helped and the proposed solutions are all for Windows. Following this forum post suggestion I tried running both and The first one worked correctly as expected but the second one just hangs in the terminal and doesnt respond to lrep or any other shell commands. Given that this seems to be the issue but I can't figure out exactly what the issue is or how to resolve it. From looking at some of the forum posts above it looks like the issue is to do with a missing configuration file when running as sudo (which is what Team City is running under as well) but I can't figure out where I should be placing the client.conf file on Mac to get this working. I have also double checked my path and that should be fine. I already have `usr/local/bin` in it and have tried adding other paths as well such as `usr/local/bin/cm` but that has not helped. I'd really appreciate some help in resolving this issue. Thanks Tom MacOS: (Big Sur - 11.1) Team City: 2021.2 Plastic SCM: 10.0.16.6179

Hi Carlos, Thanks for the reply. It was the --server argument that I was missing. Adding that in gets my test trigger working correctly (although in my case i replace the plasticscmsupport@cloud with our own cloud repo). I presume this means that on a machine where I have both distributed and centralised repos I will need to set up 2 sets of triggers, 1 for each server type? Thanks Tom

Hi Carlos, This doesn't seem to be the case. I have a couple of test batch scripts that just create a folder just to test for the after-setselector and after-update triggers. With my local repository, when I switch to a different changeset the batch files are triggered and the test folders are created. However when I do the same thing on my cloud repository those folders don't get created which suggests that those scripts aren't running or are at least having some issues. As stated I am running a version later than the one you posted so I assume it should be functional in that version. Where would I find logs to help try and diagnose the issue better? Another thought is that I was running an older version of Plastic SCM until yesterday and had actually set up some triggers on that before realising they weren't supported on that version for cloud repos. After updating I removed those triggers and created new ones but not sure if that could be relevant in some way (the repo was created in the older version of plastic although I'd like to think that shouldn't be an issue). Thank Tom

Hi Carlos, Thanks for the reply. I managed to figure out what I was doing wrong in the end it was a bit of a facepalm moment. I said this before: That part was incorrect as the missing step was running "Update Workspace" - it just wasn't in the location I was expecting. The reason for this is that I have only pressed Update workspace for my cloud repos in the Incoming Changes tab after clicking on View in the green box that appears in the gui when there are changes. However I never use that option in my usual distributed workflow and wasn't aware it was even available. My usual workflow would be to push/pull in the sync view when syncing with the cloud repo and interact with the branch explorer at other times. It was only when I noticed the "Update Workspace" button in the Workspace Explorer tab that I realised that was available here too. Clicking that resolved the issues as expected. The documentation I linked doesn't explicitly mention that the Update Workspace button is located on the Workspace Explorer view although it probably does infer it with the screenshot - crucially the screenshot doesn't show the Update Workspace button there though! It might be nice just to make that part of the documentation a little clearer but hopefully this explanation helps anyone else who's confused by that. Thanks! Tom

Hi Carlos, Is there any update on when we might expect to see this feature? This is quite a critical feature for us as we want to run some automated scripts when the user updates their workspace. We can do this with the distributed setup with a local server and sync view but the scripts we want to run are specifically for the less technical members of the team who use the cloud repo directly. I am currently running 10.0.16.6089 - do you have an eta on when we might expect to see this feature as we're past summer now! Cheers, Tom

Hi, I am looking at breaking up an existing project in to a couple of repositories so that we can make use of xlinks to share code between the original project repo and a repo for a new project. Whilst looking in to this I came across some issues that I have not been able to resolve and was hoping someone could provide some help. Our team has a mix of people creating their repos in a centralised way with @cactus@cloud and others that set up a local repository and use a sync view to push/pull to the repo in the cloud. For the new setup I have broken up functionality in to a couple of new repositories, "Tech" and "Tools" which contains common cross-project functionality. In the original project repository (in my local repository) I created an xlink to the new Tech repository as follows: cm xlink -w Source/Tech / cs:1@Tech@cactus@cloud I have committed and pushed those changes to the cloud repo. I have a second workspace for this project that is setup to track the cloud repo directly. In that workspace I am able to update the workspace as normal and i can see that the Source/Tech folder is populated with the contents as in changeset 1 of the new repo as expected. However in my other workspace which is set up as a local repo tracking the cloud repo that Source/Tech folder is empty. According to your documentation here you should update the workspace by clocking "update woekspace" in the GUI but as far as I'm aware this button is not available when creating local repos and updating via a sync view. I came across another forum post here which seems to be discussing something similar but in their case their xlink appears to be to a local repo whereas I want to set up my xlink to the cloud repo. Do I still need to adjust my sync view or create a new sync view to get this working? What is the process for syncing with an xlink at a cloud repo on a workspace for a local repository or is this not supported? Thanks Tom

Hi Carlos, That's great, thanks for updating the documentation. I had understood that was the case from the other forum posts I found though so have left the Custom Field ID blank. Yes the specific issue I am having is that the Jira tasks do not appear in the Atlassian JIRA Extension pane in the branches tab. I have attached some logs from the plastic.debug.log.txt file. I selected the refresh button on that pane at about 11.03 (towards the end of the logs) but cannot see anything relevant to JIRA in there. Thanks, Tom plastic.debug.log.txt

Hi, I am having issues getting the JIRA extension working with Plastic SCM. I was initially following the documentation found here but this forum post suggests that that documentation is out of date. I am not sure whether I am facing the same issues described in that post though so thought I should create a new one. Our teams Jira setup is using their Next Gen projects (which is not documented in the documentation linked above). To get around the issue mentioned in the forum post linked above, I have setup a short text field and named it Plastic SCM. This looks like: In Preferences->Issue Trackers I have the following settings: - Bind to issue tracking system: Atlassian JIRA - Apply binding to: Repositories - Bind issues to plastic branches - Branch prefix: jira_ - Project Key: MULTIPLE_PROJECTS - Resolved Issue States: Done - Issue Types: Bug, Task, Story - REST URL: /rest/api/2/ - TASK URL: /browse/ I have my connection details as well and when I select "Test connection" the dialog tells me that my connection was successful. However when attempting to select a task from the branches window I only see the following empty view: I've taken a look at the log files but can't find any obvious errors in there. I have tried using a specific project Id instead of multiple projects and also used the JIRA REST API to get the custom field id and tried to set that but nothing I do seems to get this to work. I would greatly appreciate any help on getting this setup as this would be a useful integration for my team. Thanks in advance, Tom Some more information: OS: Windows 10 Plastic SCM Client: 9.0.16.4511 Example Task: