Jump to content

Tom Clifton

Members
  • Posts

    7
  • Joined

  • Last visited

  • Days Won

    1

Tom Clifton last won the day on October 13

Tom Clifton had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Tom Clifton's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • First Post Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

1

Reputation

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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:
×
×
  • Create New...