Jump to content

Kieran

Members
  • Posts

    2
  • Joined

  • Last visited

About Kieran

  • Birthday 11/28/1981

Profile Information

  • Gender
    Male
  • Location
    Manchester, England
  • Interests
    Programming

Recent Profile Visitors

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

Kieran's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. OK, great. I will look into switching from CS to GUID throughout the workflow. As for the Jenkins setup, that does indeed sound very similar to what I have set up along with a after-replicationwrite too to catch changes that are replicated in. Thanks, Kieran
  2. Hi, I have noticed that when you sync repositories, the changeset numbers no not necessarily match up on the different servers. At first this was just an annoyance due to using Plastic for 3 years (without replication) prior to this point and getting very used to using CS numbers to discuss work in the depot and also as the main descriptor in automation tools. However I now have a use case which is a little more than annoying. First of all, to discuss the setup in case that has any bearing on it. Our central repository is in the Plastic Cloud. Our distributed team do a mix of connecting directly or setting up a sync view locally. Personally I have two separate servers syncing against the cloud server, one on my development machine, the other on my CI system. I have chosen to use the standard rather than the cloud edition for both of these. My two replicated repositories have differing CS numbers than on the cloud and also different from each other. It's never been more than about +/- 3 numbers, but different. My CI system is Jenkins based and the pipeline uses smartbranch to identify and sync on the correct branch/CS number using "smartbranch "%BRANCH%" changeset "%CS%"". I don't think there is another way to do this? Therefore in my CI system I need to ultimately work with CS numbers. For CI tasks this is not an issue as the system uses it's own replicated view of the Plastic server in isolation so can just use the numbers that it sees and everything is fine. The issue comes when people want to interact with the CI system. One issue is that it can be confusing to the user when a job is described by it's CS number and that does not match up with what they see in Plastic. For this issue, I am thinking that I will have to drop using the CS number completely in reports that are generated by the CI system and instead just use the comment from that CS? This will make it a lot harder for users to identify what CS a job was built against. Is there not some other globally consistent identifier for a CS? I have considered labels but I think that could end up very messy as we would end up with a lot of them. However my real problem is when users want to request that the build system perform a special build for them. How do they identify the CS that they want building? They will have no way of knowing what CS number is being used on the (invisible from them) local Plastic server in the CI system. I'm thinking that I will have to take the name of the server that they are referencing the CS number against and then somehow look-up what the equivalent CS number is on the replicated server in the CI system? Is this even possible? If someone is able to shed some light on this, it would be much appreciated. Thanks, Kieran
×
×
  • Create New...