Jump to content


Perforce change-submit trigger to run script on client

change-submittrigger validation

  • Please log in to reply
2 replies to this topic

#1 wbkboyer

wbkboyer

    Newbie

  • Members
  • Pip
  • 3 posts
  • LocationVancouver, B.C., Canada

Posted 08 April 2019 - 09:05 PM

I created a post on SuperUser, but figured I'd also come to the source of Perforce knowledge as well :D I've been looking around at various StackExchange posts, Perforce forum entries, etc. for a solution to the following problem, and would be grateful for your guidance and experience!

Problem Description

I want to be able to initiate from the Perforce server a series of validation steps on the client side on files opened within a changelist before allowing the changelist to be submitted.

For example, I wish to ensure that if a file is opened for add, edit, or remove as part of a changelist, that a particular related file will be treated appropriately based on a matrix of conditions for that corresponding file:
  • Corresponding file being opened for add/edit/remove
  • Corresponding file existing on disk vs. not existing on disk
  • Corresponding file existing in depot vs. not existing in depot
  • Corresponding file having been changed vs. not having been changed relative to depot file
These validation steps must be initiated before the submit is accepted by the Perforce server. Furthermore, the validation must be performed on the client side since I must be able to reconcile offline work with the copies on clients' disks.

Components
  • Perforce 2017.2 server
  • MacOS and Windows computers submitting to different branches
Initial Attempts
  • Initial design was a strictly client-side custom tool, but this is not ideal since this would be a change of the flow that users are familiar with, and I would also have to implement a custom GUI.
  • Among other approaches, I considered creating triggers in 2017.2; however, even if I were to use a change-content trigger with all the changelist files available on the server, I would not be able to properly perform the validation and remediation steps.
  • Another possibility would be using a change-submit trigger and to use the trigger script variables in 2017.2 to get the client's IP, hostname, client's current working directory, etc. so that you could run a script on the server to try to connect remotely to the client's computer. However, running any script on the client's computer and in particular operating on their local workspace would require credentials that most likely will not be made available.
Desired Approach

I would love to use a change-submit trigger on the Perforce server to initiate a script/bundled executable on the client's computer to perform p4 operations on their workspace to complete the validation steps. However, references that I've found (albeit from years ago) indicate that this is not possible: Thanks again for reading and for your help!

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 10 April 2019 - 07:26 PM

Quote

running any script on the client's computer and in particular operating on their local workspace would require credentials that most likely will not be made available.

This is the crux of it -- the Perforce server is not allowed to send the client arbitrary code to execute. If you want that type of functionality, you'd have to punch your own security hole in the client (and then come up with your own way of making sure it's not misused), and it sounds like you've already been down that road and decided it's not worth it.

Quote

Initial design was a strictly client-side custom tool, but this is not ideal since this would be a change of the flow that users are familiar with, and I would also have to implement a custom GUI.

My recommendation would be to start with that approach and then look for ways to decrease friction. For example, you could use a change-submit trigger to detect whether the user skipped the custom workflow (perhaps by having the custom tool put a token in the change description for the trigger to validate), and then give them an error message that puts them back on track, like "Please run Tools > Change Validator, or contact wbkboyer@yourdomain.com for help"

#3 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 172 posts
  • LocationSan Francisco, CA

Posted 17 April 2019 - 01:16 AM

Howdy!

Not to be a buzzkill (I'm going to be a buzzkill), but if I'm reading this correctly, the first three bullet points are covered by Perforce anyway, assuming folks are using it the way it is intended.

* files in a changelist must have some sort of action associated with them to get there in the first place
* Perforce can't/won't submit a file that's missing locally, it's got to have some content to submit
* a new file would have to be opened for add to be in the changelist

The last one is the only one that is sort of a thorn in my side. That can be controlled at the client level (submit unchanged files toggle.) I've given up on trying to enforce 'no unchanged revisions' because ultimately that's been a losing battle for me over the years. I've resigned myself to accepting that there will be lots of references to revisions that don't actually have deltas. It might be worth investigating, someday, a form-out trigger that sets "SubmitOptions: leaveunchanged" by default on new clients so people that are not paying enough attention will be less likely to submit empty revisions.

You implied that the script would want to run 'reconcile offline work', which reads to me that people are not using Perforce in the way it's intended to be used. If I were going down this road (again, I've been there) I would start by asking myself _why_ I'd want to do this kind of thing. Are people editing files locally without checking them out first? Are they manually setting 'allwrite' in their clients? (which is not the default.) Is there a reason people are working around the tool instead of with it?

It might be one of my very rare type-A afflictions, but I'm always weary of architecting things that hide the functionality and nature of a tool from end users. It just allows them to continue bad habits. And in a cosmic sense, I don't won't to be responsible for sending employees off to new opportunities where they might get side-eye glances when they say they're proficient in Perforce usage when in fact they are not.

Sorry if that started to sound like a rant, I didn't mean it. :)  Over the years I've just been down this rabbit hole a few times and it has never ended well. Too many weird things you have to do to possibly get Perforce to do things on the client side, where most of the time user training (sometimes with a very large stick) will fix the problem in the long term.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com





Also tagged with one or more of these keywords: change-submittrigger, validation

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users