Jump to content


Enforcing restricted changelists on a path using triggers

triggers restricted

  • Please log in to reply
5 replies to this topic

#1 davidair

davidair

    Member

  • Members
  • PipPip
  • 21 posts

Posted 28 May 2020 - 07:08 PM

We would like to enforce restricted changelists on a specific path.

According to https://community.pe...s/article/2457:

The changelist "Type:" can still be removed or changed to public by any user.  In order to enforce the changelist to always be restricted, you will want to add a trigger.

Here is an example provided by the article:

set_restricted change-commit //depot/path/to/be/restricted/... "p4 change -t restricted -f %changelist%"

However, we are struggling getting this to work because the p4 change command requires both a user and a workspace, and we cannot impersonate the originating user because their workspace is host-bound and this trigger runs on the commit server.

1. What is a proper way of writing this trigger?
2. change-commit happens too late. Is there a trigger type that happen when changes are first created? change-submit, perhaps?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 28 May 2020 - 07:36 PM

You'll want to hardcode an "admin"-permissioned user into the script (with appropriate authentication, e.g. an unlimited-timeout host-bound ticket) so that it can use the "-f" form of the "p4 change" command.

If you want to trigger on changelist creation, you could do a form trigger on changelists, but at the time a changelist is created it might not yet have files, so there's a bit of chicken and egg problem if you go that early.

Change-submit might work, but there are restrictions on modifying a changelist during submit (including within a pre-submit trigger), so you might need to experiment with that.  IIRC it's viable (if somewhat awkward) to make changes to a changelist via a pre-submit trigger, fail the submit (or let it fail automatically because you messed with the changelist), and then allow the user to resubmit unhindered.

#3 davidair

davidair

    Member

  • Members
  • PipPip
  • 21 posts

Posted 28 May 2020 - 07:41 PM

I tried testing the "p4 change" command outside of a trigger manually and it keeps complaining about an unknown client when I'm trying to pass in admin users (via -u command).

e.g. p4 change -u p4admin -t restricted -f 1234

Client 'CENTRAL_COMMIT_MACHINE_NAME' unknown - use 'client' command to create it.

Does it mean I need to maintain a separate "fake" client for those operations?

#4 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 214 posts
  • LocationAustin. Texas. Y'all.

Posted 28 May 2020 - 08:12 PM

The "-u p4admin" goes before the command.

p4 -u p4admin change <...>

#5 davidair

davidair

    Member

  • Members
  • PipPip
  • 21 posts

Posted 29 May 2020 - 02:40 PM

This is the exact command I'm using:

p4 -u p4admin change -t restricted -f 1956

However, it still complains about unknown client. Should I just create a client for the p4admin user?

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 29 May 2020 - 05:15 PM

View Postdavidair, on 29 May 2020 - 02:40 PM, said:

Should I just create a client for the p4admin user?

Yes.  Remember to set it to "locked" to make sure nobody else deletes or modifies it, since that's liable to break your script!





Also tagged with one or more of these keywords: triggers, restricted

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users