Listen for EVFEVENT signals from server

[chrjorgensen]

Changes

This PR will make C4i check the joblog after an action command has run for information about EVFEVENT file.
The joblog is checked for messages starting with EVFEVENT:, and if found, will extract the library and object from the message text.

This allows the server to tell C4i where the object was created and thus where the EVFEVENT file is located.

This change comes from a discussion in issue #2910 about building using a build tool on the IBM i, where the build tool may determine the target library. The change allows for better locating the EVFEVENT files generated and thus better diagnostics handling.

How to test this PR

Test setup:

1. create a CL source testcl.clle containing a deliberate error, e.g. dcl &var *charX 1
2. create an action TEST1 with the following command:
   CRTBNDCL QRPLOBJ/&NAME SRCSTMF('&FULLPATH') OPTION(*EVENTF) DBGVIEW(*SOURCE)
   (This action will prohibit C4i from extracting the library and object since PGM() is missing, simulating a user build command.)
3. duplicate the action TEST1 into TEST2 and insert the following command before the line containing CRTBNDCL...:
   runsql 'call SYSTOOLS.LPRINTF( ''EVFEVENT: QRPLOBJ ,testcl'' )' commit(*none)
   (This action will add a message to the joblog, indicating the location of the EVFEVENT file.)
4. change the current library to QGPL

Test on branch master:

1. remove any previous TESTCL member from QGPL/EVFEVENT file: rmvm qgpl/evfevent testcl
2. run action TEST1 on source testcl.clle. The action will fail and no diagnostics are shown. This error will appear:
   
3. remove any previous TESTCL member from QGPL/EVFEVENT file: rmvm qgpl/evfevent testcl
4. run action TEST2 on source testcl.clle. Same result as in step 2.

Test on this branch/PR:

1. remove any previous TESTCL member from QGPL/EVFEVENT file: rmvm qgpl/evfevent testcl
2. run action TEST1 on source testcl.clle. The action will still fail and diagnostics are still not shown.
3. remove any previous TESTCL member from QGPL/EVFEVENT file: rmvm qgpl/evfevent testcl
4. run action TEST2 on source testcl.clle. The action will still fail, but diagnostics are now shown!

Checklist

• have tested my change
• have created one or more test cases
• updated relevant documentation
• Remove any/all console.logs I added
• have added myself to the contributors' list in CONTRIBUTING.md

[chrjorgensen]

A friendly bump for a friendly review... 🙏

[sebjulliand]

A friendly bump for a friendly review... 🙏

On it!
I'd love to get yours on #2942 at some point, since this is mostly UX work 😉 (no rush)

[sebjulliand]

@chrjorgensen see my comments about the code (nothing serious, just some hints).

However, I couldn't get it to retrieve the diagnostic, because the filtering ont the job log fails: line.slice(7, 19).toUpperCase() === : EVFEVENT:``

The process seems very specific. Is it designed for a very specific way of specifying the EVFEVENT location or should it be more generic?

[sebjulliand]

In other words: what's the benefit of it over having a new field in the action definition to define an EVFEVENT file location? (Thinking out loud here)

[chrjorgensen]

@sebjulliand Your suggestions have been implemented - much simpler code, as you said. Thanks. 👍

I found a special case: when the first line in the joblog (stderr) is an impromptu message (no message id), the line is left-justified. If the same line comes second, it has blanks instead if message id. I guess it's our code for stderr doing the trimming?

The code for extracting EVFEVENT from the joblog has been changed to use regex instead if splice.

what's the benefit of it over having a new field in the action definition to define an EVFEVENT file location?

The whole idea of this PR is to allow the server building the objects (i.e. compiling) to tell C4i where the EVFEVENT is stored. C4i can only guess from the command in the action, but the command can change the target library when run on the server, in which case the EVFEVENT file is not in the library guessed by C4i and can't be fetched to show the errrors. The command can also issue multiple CRT-commands and produce more than one EVFEVENT file member, and this PR allows fetching all these members.

The mechanism used is to write a message (impromptu or defined message) to the joblog starting with the text 'EVFEVENT:' followed by the library and object names separated by either comma, space or forward slash. The code in the PR will pick this info up and use that instead of the guessed values - or if not found, use the code from before this PR.