Jump to content

cm mktrigger filter by repository not working


Recommended Posts

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

post-27977-0-11914900-1402967089_thumb.jpg

post-27977-0-26952400-1402967090_thumb.jpg

post-27977-0-00049200-1402967091_thumb.jpg

post-27977-0-16827100-1402967092_thumb.jpg

post-27977-0-08928100-1402967093_thumb.jpg

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 5 weeks later...

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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!

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 2 months later...

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

Link to post
Share on other sites
  • 2 weeks later...

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

Link to post
Share on other sites

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...

Link to post
Share on other sites
  • 3 months later...

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.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...