Log Filter
We installed Build Forge in the last few months; I'm posting from home
so I don't have the exact version number available. I'm a brand-new user so I'm just starting up the learning curve. Please have mercy, and if there's The Fine Manual for these questions, please give me a URL so I can Read it. Most recently, I've looked at Log Filters. The largest problems I see at the moment are - As stated in the help, if there is a log filter for a step, then it uses only the log filter to flag the step as failed/warning/succeeded, ignoring everything else -- particularly the exit result code, timeout, and anything else. - It appears to apply the filter only to the EXEC lines. Because they are not EXEC lines, I can't detect RESULT , referencing an unset variable, probably whatever message results from timeout, &c. If this were to work, this might be a way to work around the first problem above. There are lesser hardships, but I can work around them. I'm thinking these restrictions are pretty crippling. Maybe I'm missing something? Is there a way to do these? I know almost nothing about adapters; could they do anything related to log analysis? I'm thinking I'm going to have to ignore log filters and just code them myself, by redirecting to a log file and having a program analyze the log. What are all the ways a step could have a failure when there's no filter? -- Tim McDaniel, tmcd@panix.com |
8 answers
|
In article <hrcpr4>,
alloni <allonik> wrote: The filter does apply to some kinds of non-EXEC lines, Thank you for the reply. Is there a list anywhere of what line descriptors a log filter can see? EXEC, RESULT, ...? The easiest way to accomplish this task is to do something I hope that a reply of "bleah!" won't be seen as being too negative ... -- Tim McDaniel, tmcd@panix.com |
Hi, Tim.
- It appears to apply the filter only to the EXEC lines. Because they This is not entirely correct. The filter 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. What are all the ways a step could have a failure when there's no Too many possibilities to list in full - exit result, timeout on the agent side, if the agent machine suddenly drops off the network, if there are issues with the database, etc. Hope this helps, Alloni Kramer Perl Engine Lead IBM Rational Build Forge Email: allonik@us.ibm.com Phone: 512-286-2030 Tie Line: 966-2030 |
|
In article <hrcpr4>,
alloni <allonik> wrote: The easiest way to accomplish this task is to do something How would you work around the problem that, if the first step fails, it won't go on to output the log? The way I see is to have a library as the fail chain of the first step: it would look for an environment variable named by convention (log_file or some such) that's set in the first step; it would output $log_file and then die with failure. -- Tim McDaniel, tmcd@panix.com |
|
In article <hrct28>,
Tim McDaniel <tmcd> wrote: In article <hrcpr4>, I figured out a lot of it: filter on ^, Warning, and see which lines light up. Filtered: STEP, MANIFEST, EXEC, RESULT Not filtered: AUTH, MAP, SET, SSL, ENV, SCRIPT Don't know: INT, any other types that I didn't get in the test step Anyone know the full set of job output line types? -- Tim McDaniel, tmcd@panix.com |
In article <hrcpr4>, The filter does apply to some kinds of non-EXEC lines, Thank you for the reply. Is there a list anywhere of what line descriptors a log filter can see? EXEC, RESULT, ...? Not documented, no, but the list of ones we automatically skip is: SET, FILT, AUTH, MKDIR, RMDIR, LOG, PTY, SSL, REGEX ENV, MAP, BOM, and SCRIPT. Any other lines are processed. The easiest way to accomplish this task is to do something I hope that a reply of "bleah!" won't be seen as being too negative ... Heh. You're not the only one to feel this way, and we are restructuring the way log filters work to allow your desired behavior in the next major release, but that won't help you for now. Sorry about that. Alloni Kramer Perl Engine Lead IBM Rational Build Forge Email: allonik@us.ibm.com Phone: 512-286-2030 Tie Line: 966-2030 |
That would probably be the easiest way of doing that, yes. There are other ways, involving continue-on-fail and environment variables, but they're probably more trouble than they're worth. Alloni Kramer Perl Engine Lead IBM Rational Build Forge Email: allonik@us.ibm.com Phone: 512-286-2030 Tie Line: 966-2030 |
That would probably be the easiest way of doing that, yes. There are other ways, involving continue-on-fail and environment variables, but they're probably more trouble than they're worth. Oh, and also, if you're doing something on a Unix-type machine, you might try the "tee" command, which duplicates output into a file. For example: ls -aF | tee file.txt will cause the output of ls to appear on standard output as well as being copied to file.txt. Alloni Kramer Perl Engine Lead IBM Rational Build Forge Email: allonik@us.ibm.com Phone: 512-286-2030 Tie Line: 966-2030 |
|
In article <hrfqmk>,
Tim McDaniel <tmcd> wrote: In article <hrct28>, *except* that the log filter appears not to be applied at least to the EXEC output of the .source adaptor that we use. If I understand it right: it does an accept of an RTC workspace. One of the components had two flow sources. Trying to accept from it caused a fatal exception. One of the EXEC output lines had only "BUILD FAILED". "BUILD FAILED" is one of the fail patterns in the log filter. It was not flagged. RBF declared that the step had succeeded and proceeded. Build Forge 7.1.1.4. -- Tim McDaniel, tmcd@panix.com |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.