Cross-platform Client-side triggers

[LoganBarnettASU]

Hello,

My team is working in a mixed OS X and Windows environment. We want the triggers we make to work on both systems, but I suspect our problem is that the paths we're using aren't valid for both operating systems.

$ cm listtriggers

2 Update art on update ruby /Users/atlantisremixed/.arx-plastic/update_art.rb LoganBarnett after-update

The Ruby script we're running works great for both OS X and Windows when running standalone, but that path won't work for WIndows in the trigger so it doesn't even get to the Ruby script.

What can I do to make my trigger platform agnostic? All of the examples in the PDF seem to prefer one platform or another, but never something universal. It would be nice if I could just do ~ for a home directory but I don't think that expands correctly. Perhaps I was doing that wrong?

Thanks in advance!

-Logan

[manu]

Hello Logan,

the update triggers are client side triggers, they are executed in the client machine.

The MAcOS "/Users/...." path is not valid for a Windows machine so you need to install ruby in the windows machine and create an update trigger in the windows machine.

In this way the MacOs machine will run the MacOS trigger and the Windows machine the Windows trigger.

Are you using shared workspaces?

[LoganBarnettASU]

Manu,

I don't believe we're using shared workspaces. I've created a new workspace under a different user for each machine we have Plastic installed on.

I assume that the owner of the trigger (in this case it's me) should be the only user the trigger is fired against. In our case this one trigger is firing against every user on different machines. Perhaps this is the real problem? I thought this behavior was to prevent us from having to write a trigger a bunch of times, but in light of this path issue, I'd say making independent triggers makes more sense.

-Logan

[LoganBarnettASU]

I tried making the trigger locally (whereas I was making it on the server before). This resulted in the same behavior (runs on all systems). Here's my maketrigger command:

cm maketrigger after-update "Update art on update (root)" "ruby /.arx-plastic/update_art.rb"

Are there any switches I can pass that would make it work for just me?

[manu]

I really don't understand this, the after-update trigger is a client local trigger.

Can we schedule a gotomeeting sessions in order to get more information?

[manu]

Hi again Logan,

I'm sorry, you are right. I've just added the task into the bug tracking system and we-ll change the behavior.

[LoganBarnettASU]

My workaround for the time being is to place the Ruby file in a root directory (/foo/bar.rb or c:\foo\bar.rb), and then the trigger looks like this:

cm maketrigger after-update "after update" "ruby /foo/bar.rb"

That seems to work for us. It's actually kind of nice in that we don't have to configure this trigger for each machine. The only drawback is that we need root/admin access, but we were able to work around that with sudo and running as administrator on Windows.

[manu]

It good to hear that the "....rigger after-update "after update" "ruby /foo/bar.rb"" trick worked!

That seems to work for us. It's actually kind of nice in that we don't have to configure this trigger for each machine.

Yes but I think it can be confusing since you can think that it's only a local client trigger.... I have added a task into our bug tracking system in order to allow both behaviors.

[psantosl]

Hi,

Yes, you've to be careful with client paths on multi-platform setups. This has always worked this way.

There's a good option which would be supporting some sort of multi-path thing.

The alternative is also creating a script (script on linux, .bat on windows) located in a path partial to the cm.exe location, with different actions depending on the operating system.

This one is actually a good example of a use case that we should document.

Manu, please, change the "bug" by "improve docu", and let's get it blogged.

[gweronimo]

Hi there! This stumped us too. It seems this has still not been added to the documentation?

We discovered by experimenting that the client-side triggers are not purely "client-side" but rather "server-provided client-executed trigger". Our first interpretation of the Triggers Guide was that we would need to setup a client-side trigger on each client machine, but we soon discovered that this led to *many* client-side triggers. ;D We then went back to the Triggers Guide and to our surprise we found no mention of this fact.

This really has to be explained better!

Best regards,
Göran W.