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.

[richardm90]

When reading issue #2910 this sounded very similar to a problem I'm experiencing though I'm working with source members rather than IFS files.

If I compile a display file into a different library than the source exists I see the following error message in the output.

CPF5715: File EVFEVENT in library RMVSCODE not found.

It works fine when compiling an RPGLE source member.

I was debugging and found the problem.

src/ui/actions.ts

This code updates the evfeventInfo.library property if the getObjectFromCommand function returns a value to possibleObject.

src\ui\action.ts

This code works fine when the command contains OBJ, PGM, etc but not doesn't check for FILE.

Just thought it worth mentioning. You're right C4i is trying to work out where the EVFEVENT file is located but fails with display files (and I guess any DDS) source members.

[chrjorgensen]

@richardm90 Good find and impressive debugging! 👍

I will add FILE to the regex pattern, so output from CRTPF, CRTDSPF, CRTPRTF and more will be identified like currently for programs, modules and more.

[chrjorgensen]

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)

I don't think that will work - it's the CRT-command which decides where to create the EVFEVENT file object, in the library together with the object created. And an action can never control that. The command in the action can be anything besides a CRT-command and can do anything to create one or more objects in one or more libraries. One action does not always produce one EVFEVENT object, it can produce multiple EVFEVENT files.

That's why this PR will make the server return the information and C4i pick it up - and the most obvious communication channel is the joblog, which is read anyway.

@richardm90 discovered that the code did not look for FILE objects - this has been added in commit e3d8d6e.