Mismatching changeset numbers in sync'ed repositories

[Kieran]

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

[manu]

Hello @Kieran,

all the Plastic SCM objects are having an internal GUID. The GUID is extremely useful when you deal with distributed scenarios. As you pointed out you can't rely on the changeset ID, you will need to use the changeset GUID.

The best setup you can have with Jenkins comes by using the Jenkins API and parametrized builds.

It basically consists in having a Plastic SCM after-checkin trigger that will be fired based on you preferences (certain branch, certain owner, certain comment, certain attribute set...), the trigger will then request Jenkins a new parametrized build, the job, workspace to use and more importantly the changeset GUID to build will be used among other preferences in order to start the build.

Finally, at the Jenkins build node you will use the changeset GUID to run the "cm switch --changeset=Changeset_GUID" command and start the build job.

We are preparing a blogpost explaining it in details

 

 

[Kieran]

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

[manu]

4 minutes ago, Kieran said:

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.

Great! That's also a great place to start triggering build!

Keep us tuned, we would like to help as much as possible, we are about to start improving all the devops area and all the feedback is more than welcome.