Jump to content


How can we avoid integrating changes from one branch to other in perforce?

triiggers

  • Please log in to reply
34 replies to this topic

#1 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 03 July 2019 - 04:22 AM


I am new to perforce. I have a requirement to create a trigger to avoid integrating changes from one particular branch say 'branch_testing' to 'main' branch.

Can you please share some sample script which will avoid integrating changes from one branch to other?


#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 03 July 2019 - 07:11 AM

If you want to absolutely prevent changes from going from branch_testing to main, you need to use the protections table and do one of two things:

1) Remove "read" access to branch_testing.
2) Remove "write" access to main.

Otherwise, even if you implement clever controls on the integrate command, there's nothing to stop a user from doing:

p4 sync branch_testing/...
p4 edit main/...
cp -R branch_testing main
p4 submit


#3 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 03 July 2019 - 09:48 AM

Actually we want other branches to integrate the changes to main branch. My requirement is, i want to prevent only that particular branch 'branch_testing' changes to integrate to main branch.'' We can achieve this only through trigger i guess?

If we remove the write access, We cant integrate the changes from other branches right ?

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 03 July 2019 - 03:34 PM

View PostNaveen kumar pet, on 03 July 2019 - 09:48 AM, said:

If we remove the write access, We cant integrate the changes from other branches right ?

Correct.  If that's the case, the only way to *absolutely* prevent changes from getting from branch_test to main is to remove "read" access to branch_test, since that will stop users from being able to see those changes (at which point they will have all sorts of ways of getting them into main -- they can copy them over directly, they can copy them to another branch and integrate them from there, etc).

If you just want to discourage changes from going from branch_test to main, there are a bunch of options, but make sure you understand that all of these are just ways to discourage, not prevent.  If a user perceives that the only way to accomplish what they're doing is circumvent your trigger, they will probably find a workaround (and their workaround will probably be worse than the thing you were trying to prevent).

1. Use streams.  If branch_test is a "development" branch, the default behavior is to block merges to main.
2. If users typically use branch specs to integrate, do not define a branch spec from branch_test to main.
3. Set up a trigger that runs on main and checks the source of integrations (via the "p4 resolved" command).
4. Run a regular report on the source of changes integrated to main (e.g. via "p4 filelog"), and notify users who are engaging in bad practices (and/or undo those changes).

#5 Dave Foglesong

Dave Foglesong

    Member

  • Members
  • PipPip
  • 12 posts

Posted 03 July 2019 - 03:59 PM

It depends on the exact requirements you're working with, but removing "=branch" permissions might be an option. From "p4 help protect":

=branch - if this right is denied, users are not
  permitted to use files as a source
  for 'p4 integrate'

So if you remove =branch permission from the testing branch, that will prevent integrations to other branches. e.g., something like this in the protect table:

write user * * //depot/...
=branch user * * -//depot/testing/...

Will prevent users from running "p4 integrate //depot/testing/... //depot/main/..."

But note that this prevents ALL integrations from testing -- not just to main, but to all other branches as well. If that's OK, this might work for you. But if you need to allow integrations from testing to other branches, then you'd need to write a broker filter script (if you're using a broker) or a trigger.

#6 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 04 July 2019 - 01:23 AM

Thanks Dave,Sam.

Trigger is the only option for my requirement.

#7 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 04 July 2019 - 03:52 AM

Sam, Your 3rd option suits my requirement:
3. Set up a trigger that runs on main and checks the source of integrations (via the "p4 resolved" command).
It means if people run integ command from branch_private -> main, We need to run trigger script on all the files which are opened on the client.  Script should run p4 resolved command on those files and it has to deny when the integrations are coming from branch_private.

BTW, i tried to integrate one file from branch_private -> main, On opened file on my client i just want to check what is the source of integration, I ran 'p4 resolved' but it says 'No file(s) resolved. '

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 04 July 2019 - 05:39 AM

View PostNaveen kumar pet, on 04 July 2019 - 03:52 AM, said:

BTW, i tried to integrate one file from branch_private -> main, On opened file on my client i just want to check what is the source of integration, I ran 'p4 resolved' but it says 'No file(s) resolved. '

Before someone can submit an integration, they need to resolve.  Your opened file was not resolved; if you tried to submit it, it would fail even with no trigger in place.

#9 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 04 July 2019 - 05:52 AM

Yeah, I miss to resolve the file.

Now i can see the following output for p4 resolved command.

[npet@test-npet hdl_branch]$ p4 resolved
/test/workspace/npet/test_branch/main/vplan/Enet_xt__top.vplan - copy from //depot/vip/src/branches/branch_private/cvip/enet_xt/vplan/Enet_xt__top.vplan#80

Now i need to write a script parsing that p4 resolved command and see if there is any files integrating from branch_private and exit the run right ?

Is there any other simple way, Without parsing the output and finding the branch from where it is integrating . Do we have any direct command which will give the branch name from where its being integrating?

#10 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 04 July 2019 - 07:29 AM

You can use the -F global flag to pull out just the fromFile, since that's the part you care about:

C:\Perforce\test>p4 resolved
c:\Perforce\test\bar - copy from //stream/main/foo#1,#3
c:\Perforce\test\bar - resolved filetype from //stream/main/foo#1,#3

C:\Perforce\test>p4 -F %fromFile% resolved
//stream/main/foo
//stream/main/foo

Since your "branch name" is an arbitrary subset of the filename, you'll need to supply your own logic to extract the branch name from the fromFile.  Based on your example looks like you could easily do it by having a regex that captures everything in between the sixth and seventh "/" character.

#11 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 05 July 2019 - 06:24 AM

Thanks Same.
It helps :)

#12 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 05 July 2019 - 11:07 AM

Hi Sam,

I have files opened on my client with pending cl# 952366

When i try to run the command explicitly i am not getting any output :

Command : -/lan/common/pkgs/perforce/v2015.2/bin/p4 -p p4server:1800 -F %fromFile% resolved -c 952366

No output from the above command, When i run 'p4 opened -c 952366' i can see the output as expected.

My script look like this :-

#!/grid/common/pkgs/perl/v5.12.2/bin/perl
use strict;
use warnings;
my $Client = $ARGV[0];
my $ChangeNum = $ARGV[1]; #change number
my $Port = "p4server14:1900";
my $p4 = "/grid/common/pkgs/perforce/v2015.2/bin/p4 -p $Port";
# get list of files opened under the changelist being submittedm
my @files = `$p4 -Ztag -F %fromFile% resolved -c $ChangeNum` -C $Client;
print " files are @files";
if (@files){
  foreach my $file (@files){
chomp($file);
if ($file =~ /\/\/depot\/vip\/src\/branches\/private_branch\/.*/i){
print "Integrations from private_branch -> main is not allowd";
exit( 1 );
}
}
}

Command to run script :- ./test_commit.pl cheruvu_client 952366

#13 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 05 July 2019 - 06:58 PM

Your script doesn't specify which client it's using -- how do you know it's running the command against the same client that has the files open?

#14 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 07 July 2019 - 01:36 AM

Hi Sam,
I have just updated my script. Could you please check?
I specified with mentioning client. I am still hitting the issue. Seems like i am missing something in p4 command.

Thanks,
Naveen

#15 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 07 July 2019 - 09:09 AM

Run the command in such a way that you can see what error it's returning (running it without the "-F" and redirecting to stderr, or using the "-s" global flag, should do that) and print that out.  That should get you pointed in the direction of the next thing to debug.  :)

#16 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 08 July 2019 - 01:49 AM

Hi Sam,

The issue is with command only. When I don't give -C <client_name> , -c <cl_number>. Script works fine.

Command :-
/grid/common/pkgs/perforce/v2015.2/bin/p4 -p  p4server14:1900 -F %fromFile% resolved  ====> Works.

/grid/common/pkgs/perforce/v2015.2/bin/p4 -p  p4server14:1900 -F %fromFile% resolved -c 952366 -C cheruvu_client ====> Not working.

I am running the script on my client, Where client is already set. We know that for triggers we can pass client name(%client%) and pending cl#(%change%)  automatically to trigger script. But before that i want to give a test passing manually. Not sure whats wrong in my command. I can see that files are opened on my client with cl#952366.

#17 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 08 July 2019 - 04:19 PM

"Not working" isn't an error message.  As I said, you will need to debug by removing the "-F %fromFile%" so you can see the error being returned.  

There's no point trying to guess which error condition you're hitting when the server will just tell you.  ¯\_(ツ)_/¯

#18 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 09 July 2019 - 02:18 AM

Yeah. Sorry i didn't try that.
I am hitting this issue When i try running without '-F  %fromFile%'

/grid/common/pkgs/perforce/v2015.2/bin/p4 -p  p4server14:1900 resolved -c 952366 -C cheruvu_client  

O/p :- Usage: resolved [ -o ] [files...]
  Invalid option: -c.  

It seems like we cant use -c for resolved. When i replace resolved with opened in above command it works fine. But i need to get the from files (Source of integration) here.

#19 Naveen kumar pet

Naveen kumar pet

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 09 July 2019 - 02:53 AM

Sam, Does p4 resolved command wont work for single file?

I am trying to get each file from 'p4 opened' command output and try to check each file with 'p4 resolved <file_name>' . it says  : <file_name>  - no file(s) resolved.

When i just run 'p4 resolved' no file as argument. it shows the source of integration. But if i give one file as argument it's not showing any output. I cant find any flags over perforce forum except -o for p4 resolved command.

#20 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 09 July 2019 - 07:32 AM

When you give a file argument to "p4 resolved", it can match either the "localPath" or the "fromFile".  Local/client syntax paths match the target, depot syntax paths match the source.

Maybe you want something like:

p4 -Ztag -F %clientFile% opened -c CHANGE | p4 -x - resolved





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users