cm mktrigger filter by repository not working

[nqramjets]

Per the release notes for 5.0.44.570 the new --filter command should allow me to specify a specific repository for triggers to fire on

 

See http://www.plasticscm.com/download/releasenotes.aspx (I couldn't paste it, and the link java thing froze the page)

 

1. Create a testing repository called TestRepo (TestRepo1.jpg)

2. Setup a trigger which will simply fail for use in exploratory testing (TestRepo2.jpg)

@echo off
echo %PLASTIC_USER% : %PLASTIC_REPOSITORY_NAME%
exit 1

3. Attempt to create a label: Success (TestRepo3.jpg)

4. Remove trigger and recreate without the --filter option (TestRepo4.jpg)

5. Attempt to create a label: Failure (TestRepo5.jpg)

 

Notice that I'm using the correct version (TestRepo4.jpg)

 

So, do I have the syntax wrong or is the filter option simply broken?

 

Thanks,

Ryan

[calbzam]

Hi,

 

Yes, I´m able to reproduce the issue. As a workaround, if you use the next command to create the trigger, it will properly work:

 

cm mktrigger before-mklabel "failurelabel" "c:\path\test_fail.bat" --filter=rep:TestRepo,*

You would need to add ",*" characters after the repository name.   We will fix it as soon as possible to allow using the same command as you did.

 

 

Sorry for the inconvenience, regards,

Carlos

 

[nqramjets]

Hi Carlos,

 

I was able to get this to work, but I had to wrap the filter expression in quotes like this (to make it work in powershell):

cm mktrigger before-mklabel "failurelabel" "c:\path\test_fail.bat" --filter="rep:TestRepo,*"

Without using quotes I found that a "cm ltr" would not include the trailing ",*" which made it the same as my previous post, and therefore unfunctional. I created the trigger in windows command prompt using exactly your syntax and it included the ",*" portion as expected.

 

Thank you very much for the workaround.

 

Thanks,

Ryan

[calbzam]

Hi,

 

I´ve been reviewing a bit more this task, and actually it´s not a bug. But we should improve the documentation because the usage is not very clear:

 

cm mktrigger before-mklabel triggerSample c:\Users\carlos\Desktop\test.bat  --filter=TestRepo,*LB*

The first field is the repository name and the second field is the trigger filter. In my example, I´m filtering the "TestRepo" repository and the "*LB*" label creation pattern. It would be better to allow indicating only the repo name, but at the moment you need to indicate both parameters.

 

 

Regards,

Carlos

[nqramjets]

Oh I see, then yes the examples posted in the release notes are misleading.

 

A follow-up question though: You say

 

I'm filtering the "TestRepo" repository and the "*LB*" label creation pattern

What does the LB refer to in this instance? Does the LB indicate that it applies to labels, or only labels the a name like *LB*, or something else? I guess maybe just some more-complete documentation will explain it.

 

In the release notes it only shows the inclusion of another filter by using the pipe | and then a filter on file extension, which does not appear to be what this is.

 

I also noticed (related to trigger documentation) that there is a "security (after-security)" trigger in "cm showtriggertypes" which appears not to be documented in the Triggers Guide.

 

Thanks,

Ryan

[calbzam]

Hi,

 

It´s a pattern for the label name: *LB* . It applies to labels like *LB*.  If you want to apply the filter to all label names, use just* .

 

Yes, I agree that we should improve the documentation. At least the command help.

 

Regarding the security trigger, I´ve been checking it and it seems deprecated from  former Plastic version. Anyway, I will try to perform more tests, to check if it is still working in Plastic 5.

 

 

Regards,

Carlos

[nqramjets]

I see, so then would be correct to say that this portion of the syntax is used to further match on the name of the XXX in a trigger of type "before-mkXXX"?

 

For example:

cm mktrigger before-mklabel "TriggerName" "TriggerPath" --filter=RepoName,*LB*

would filter for labels created in RepoName whose name included the letters LB, while

cm mktrigger before-mkbranch "TriggerName" "TriggerPath" --filter=RepoName,*BR*

would filter for branches created in RepoName whose name included the letters BR?

 

If that's the case then I would assume this doesn't apply for filters on triggers like before-checkin, as there is no "name" for the checkin?

 

I'm curious because I'll need both for my current project, and it seem unintuitive to include a ",*" for something like mkbranch if there is no name for it to reference.

 

Thanks,

Ryan

[calbzam]

Hi,

 

In the checkin/checkout triggers, this syntax apply to filter the file name:

 

eg:

cm mktrigger before-checkin "TriggerName" "TriggerPath" --filter=RepoName,*.cs

Regards,

Carlos

[nqramjets]

Ah, of course! That makes much more sense.

 

Thanks again!

 

-Ryan

[manu]

Hi Ryan,

 

remember that the same happens for the rest of triggers, the filter always is applied to the object that is causing the trigger.

[nqramjets]

For posterity: Do not forget the "rep:" portion of the repository trigger filter condition. Without it the trigger will be applied to ALL repos.

[manu]

Yep, thanks.

 

That's the default behavior.

[nqramjets]

Hi manu,

 

Is it possible to setup a before-checkin trigger to filter based on the branch we're trying to checkin to? I've looked through the checkin triggers and am surprised to see that there is no $env:PLASTIC_BRANCH_NAME or anything.

 

How can I tell where I'm checking into in a trigger?

 

Thanks,

Ryan

[calbzam]

Hi,

 

If you are creating a "before-checkin" trigger, in the standard input, you are getting the branch name. You can develop your trigger based on this value. (http://plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide.shtml)

 

Standard input:

 

The standard input receives revision identifiers for all the items involved in the checkin operation, one per line. Each of them is a specially formatted string, containing the server's path of the item (independent of any workspace) and the revision specification, so its contents are easily retrieved using the cm cat command.

 

This is the format of the revision specifications, one per line:

 

item_path#br:branch#rev_no;rev_id@rep:rep_name@repserver:server

 

The meaning of the members in italic is detailed in the following table:

 

item_path The revision's path in server format, which is independent of the client workspace and operating system.

branch The branch of the revision.

rev_no The revision number, inside the branch, of the revision.

rev_id The revision unique identifier. Can be used to ease parsing when accessing revisions with 'cm cat' or 'cm shelve' in the trigger script, as string after the first semicolon uniquely identifies the revision inside the server.

rep_name The repository name where the revision belongs.

rep_server The repository server where the repository belongs.

 

Regards,

Carlos

[nqramjets]

I see. It appears that the "branch of the revision" is the destination branch, not the branch the which contains the original changes.

 

Is this simply always the same for every line in the stdin then? I guess it must be. I'm asking because I'd like to know if it's safe to only look at the first line to see if we're trying to check in to a particular branch.

 

Thank you!

[calbzam]

Yes, the standard input receives revision identifiers for all the items involved in the checkin operation, one per line.   The branch value is the branch where you are committing the changes.

 

Regards,

Carlos

[nqramjets]

Excellent! Thank you Carlos!

[nqramjets]

Hi Carlos, a follow-up question:

 

How is rev_id determined?

 

We have a before-checkin trigger which is firing after a merge into our integration branch happens. It was my impression that the rev_id would be the changeset # that signified the most recent changeset in the history.

 

My question is this: Does the changeset # that is provided always come from the most recent change to the file, or does it come from the changeset that is being committed?

 

Thanks,

Ryan

[nqramjets]

Some feedback on this would be very helpful. We have rules based on the owner of the branch which contains the changeset that I indicate in my previous comment. We are having problems, however, as the changeset that it provides does not always appear to come from the branch that was merged just before the commit.

 

Thanks,

Ryan

[manu]

Hi!

 

I'm sorry but Carlo's information seems to be out of date. Look this is the current information:

 

status item_path item_type#br:branch;changeset:cset_id@rep:rep_name@repserver:server

 

And we don't have rev_ids anymore, now the quivalent is the cset_id.

 

 

We are having problems, however, as the changeset that it provides does not always appear to come from the branch that was merged just before the commit.

 

You can't rely on the changeset_Id.... maybe the revision you are changing is coming from a completely different branch? Can you tell me what are you trying to achieve? Maybe I can help you with that...

[nqramjets]

What we want to do is know where a commit came from (when merging). To say it another way, we want to know what the pending merge links are.

 

We can't use the cset_id because this is not necessarily from the branch which was the source of the merge.

 

I've read this post, but would prefer not to do this (partly because this would be a client-side trigger): http://www.plasticscm.net/index.php?/topic/1132-permissions-to-enforce-integration-rules/?hl=%2Bpending+%2Bmerge#entry6608

 

An alternative would be to use something like "cm status" to get the (Merge from 1234) and parse this, but again, this would need to be a client-side trigger.

[calbzam]

Hi,

 

Please, feel free to add your suggestion to improve our trigger information:

 

https://plasticscm.uservoice.com

 

Regards,

Carlos.

[nqramjets]

Added this to UserVoice here: https://plasticscm.uservoice.com/forums/15467-general/suggestions/7072603-improve-checkin-trigger-information-to-include-pen

 

Thanks,

Ryan

[manu]

Thanks Ryan!