I want my log filter to catch exit codes, and in addition some patterns, how can i do it?

when i configure a log filter with my patterns it doesn't catch the exit codes.

Thanks,
shiran

Hi shiran,

There is a discussion of this topic in the posts at http://jazz.net/forums/viewtopic.php?t=10342 .

alloni's message on Thu, Apr 29, 2010 4:14, starts the discussion about how this can be achieved.

This is a selection from that post:

The easiest way to accomplish this task is to do something similar to your solution. Create two steps:
- One which runs your step and logs it to a file. This step should have no log filter, so will fail as usual if something goes wrong with your step.
- A second which outputs the contents of the log file (via cat or type or whatever is appropriate for your OS). This step should have the log filter set, which will then pattern match on the output of the previous step, doing whatever is appropriate at that point.

bju

In article <hs933v>,
bju <ulbricht> wrote:

shiranswrote:
I want my log filter to catch exit codes, and in addition some
patterns, how can i do it?

when i configure a log filter with my patterns it doesn't catch the
exit codes.

There is a discussion of this topic in the posts at
http://jazz.net/forums/viewtopic.php?t=10342 .

alloni's message on Thu, Apr 29, 2010 4:14, starts the discussion
about how this can be achieved.

This is a selection from that post:

The easiest way to accomplish this task is to do something similar
to your solution. Create two steps:
- One which runs your step and logs it to a file. This step should
have no log filter, so will fail as usual if something goes wrong
with your step.

- A second which outputs the contents of the log file (via cat or
type or whatever is appropriate for your OS). This step should have
the log filter set, which will then pattern match on the output of
the previous step, doing whatever is appropriate at that point.

For convenience, I think that first step needs to have a fail
chain to a project that filters the log file and then exits with
failure (".stop Failed", I think). Otherwise, if the first step
fails, nothing in the log file will be output, so neither the Build
Forge log nor the user will have the failure messages. (The user
could log into the build agent's machine and look at the file system,
but (1) that's awkward and (2) it still isn't in the Build Forge log
for future reference.)

I've not implemented this notion yet -- it's next on my to-do list.
Things I'm going to investigate and experiment with:
- a project can have a fail chain. Can it inherit .tset variables,
or just .bset variables, or neither?
- could the log filtering be an inline?


Is ".stop Failed" correct, by the way? The on-line documentation just
says ".stop <state>" without saying what the exact valid
values are.

--
Tim McDaniel, tmcd@panix.com

In article <hsc9t7>,
Tim McDaniel <tmcd> wrote:

Things I'm going to investigate and experiment with:
- a project can have a fail chain. Can it inherit .tset variables,
or just .bset variables, or neither?

One of the integrated help pages is

Environment variable inheritance in chained projects

When a project is launched through a chain, the system applies
environment variables from the calling project. They are applied
differently depending on whether the called project is called as an
Inline chain or as a Conditional chain (Pass Chain or Fail Chain).

* Inline chain: the steps of the chained project are executed as
though they are part of the calling project. ...

* The system applies all the environments that are relevant. The
called project sets up variables from the calling project's
environment and its own environment in the following order:

1. Called project server environment.

2. Calling project's variables, in a set, with BF_ variable
names changed to BF_CALLER.

3. Called project server environment (applied a second time in
case it was modified by the caller's variables).

4. Called project environment.

5. Step environments (if specified) as they are executed.

Parent topic: Chaining projects together

Point 2 appears to be false, except for the BF_CALLER_.* variables.
The calling project has an environment that includes

REFERENCE_TO_UNSET_VARIABLE_1 ${UNSET_VARIABLE_1}
VAR_SET 0
VAR_PROJECT Set in play environment

One of its steps has a Fail Chain entry to another project. The
chained project has no environment of its own, and neither does its
only step. The Job output of the chained project contains no
references to VAR_SET or VAR_PROJECT, except to complain that its
references to $VAR_SET and $VAR_PROJECT are undefined.

Whisky Tango Foxtrot? Am I doing something wrong? This is the latest
Build Forge, BTW.

--
Tim McDaniel, tmcd@panix.com

In article <hscd7a>,
Tim McDaniel <tmcd> wrote:

In article <hsc9t7>,
Tim McDaniel <tmcd> wrote:
Things I'm going to investigate and experiment with:
- a project can have a fail chain. Can it inherit .tset variables,
or just .bset variables, or neither?

One of the integrated help pages is

Environment variable inheritance in chained projects
....
* The system applies all the environments that are relevant. The
called project sets up variables from the calling project's
environment and its own environment in the following order:

1. Called project server environment.

2. Calling project's variables, in a set, with BF_ variable
names changed to BF_CALLER.
....

Point 2 appears to be false, except for the BF_CALLER_.* variables.

Memo to self: when I change environment A snapshot S, make sure that
the project actually *uses* environment A snapshot S and not, say,
environment A snapshot YOWZA. *blush* My apologies for my oversight.
Using the same snapshot consistently made it work.

The calling project has an environment that includes

VAR_SET 0
VAR_PROJECT Set in play environment

More details: The step in the calling project does

.set env "the appropriate environment" "VAR_SET=new value"
.bset env "VAR_BSET=wibble"
.tset env "VAR_TSET=wobble"

(VAR_SET is in "the appropriate environment". VAR_BSET and VAR_TSET
are not.) VAR_STEP is a variable in the step's environment. The fail
chain or pass chain sees the correct values for

VAR_PROJECT
VAR_STEP
VAR_SET
VAR_TSET

but does not see

VAR_BSET

The inline sees correct values for all of them.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The documentation should be improved. The docco for .bset says

env changes the value of one or more project environment
variables for a running job. The change takes effect immediately
in the current step.

.... except page "Changing variable values during step execution" says
"Changes made using .bset take effect in the step *after* the step
where .bset is used.". The latter explains the behavior if "the step
after" is interpreted to exclude steps run by chaining the current
step. But, by experimenting, I see that this .bset variable IS
available from an *inline* for the current step.

The .tset docco says

The command takes effect in the current step. It takes
effect for all commands in the step and for any Inline specified
for the step.

But it doesn't say it is passed to *chained* projects.

--
Tim McDaniel, tmcd@panix.com

In article <hse8bg>,
bju <ulbricht> wrote:

Is ".stop Failed" correct, by the way? The on-line
documentation just
says ".stop <state>" without saying what the exact
valid
values are.

The most likely values that you would use are P for Pass (.stop P), W
for Warning (.stop W), F for Fail (.stop F), and B for Break/Stopped
(.stop B).

I agree the documentation needs to be updated with the valid values.

I don't know the protocol: will you be opening a defect for that, or
can I, or what?

It would also be good to specify what to do with invalid values. I am
now consumed with curiosity to know what it does with

.stop Hammertime

--
Tim McDaniel, tmcd@panix.com

Is ".stop Failed" correct, by the way? The on-line documentation just
says ".stop <state>" without saying what the exact valid
values are.

Hi Tim,

The most likely values that you would use are P for Pass (.stop P), W for Warning (.stop W), F for Fail (.stop F), and B for Break/Stopped (.stop B).

I agree the documentation needs to be updated with the valid values.

bju

In article <hsehsj>,
Tim McDaniel <tmcd> wrote:

It would also be good to specify what to do with invalid values. I am
now consumed with curiosity to know what it does with

STEP .stop Hammertime
ERROR Invalid final build status 'HAMMERTIME', needs to be one of P(ass) F(ail) W(arn), or B(reak).

--
Tim McDaniel, tmcd@panix.com

I don't know the protocol: will you be opening a defect for that, or
can I, or what?

It would also be good to specify what to do with invalid values. I am
now consumed with curiosity to know what it does with

.stop Hammertime

--
Tim McDaniel, tmcd@panix.com

Hi Tim,

I opened a defect for updating the documentation. You can track its progress with this link - https://jazz.net/jazz08/web/projects/Rational%20Build%20Forge#action=com.ibm.team.workitem.viewWorkItem&id=15716 .

If you want to submit a bug or request in the future, there is a link on this page - http://jazz.net/projects/rational-build-forge/ under the 'Participate' section on the right.

A step with .stop Hammertime stops with a build result of Failed. I've copied the message from the step log below.

8 5/12/10 12:11 PM STEP .stop Hammertime
9 5/12/10 12:11 PM ERROR Invalid final build status 'HAMMERTIME', needs to be one of P(ass) F(ail) W(arn), or B(reak).

bju