Open ayushikumari3 opened 4 months ago
This would be best placed in the IJvmserver manager (and its implementation).
Possibly a few additions required:
ICemt.perform
, but in the IJvmserver manager). e.g.: public void perform(String type, String action, String... options)
: jvmserver.perform("JVM", "GATHER", DIAGNOSTICS");
public List<IJvmserverDiagnosticFile> getJvmserverDiagnosticsFiles()
- creating a separate class for IJvmserverDiagnosticFile
would then allow easy introspection.Sounds good @SoftlySplinter . I wouldn't worry about dissection of the file using the API though. I think if the jvmserver calls the diagnostics, then the galasa manager should collect the tar/zip/whatever the archive is and add it as a test artifact.
Then it will appear when the test artifacts are all downloaded with galasactl runs download --name J512
for example.
We already have the following methods which may be helpful:
galasa-managers-parent/galasa-managers-cicsts-parent/dev.galasa.cicsts.resource.manager/src/main/java/dev/galasa/cicsts/resource/internal/JvmserverImpl.java/#saveDiagnosticsToResultsArchive
to copy things from the diagnostics folder into the test archive.How to get the stimulus that the test has failed ?
galasa-managers-parent/galasa-managers-cicsts-parent/dev.galasa.cicsts.resource.manager/src/main/java/dev/galasa/cicsts/resource/internal/CicsResourceManagerImpl.java
contains this:
public Result endOfTestClass(@NotNull Result currentResult, Throwable currentException) throws ManagerException ...
So it might be good to hook into that, with perhaps an indicator flag to say whether the test does/doesn't want to take the full diagnostics dump if the test failed ? The value could be drawn from a CPS property which can be over-ridden ? eg: cicsts.
Right now, the Galasa team is working on Github actions and Java 17 support, so we're not likely to be able to implement this ourselves for a while. Is there any chance we could work with someone in your team to look at it together ? (and use your CICS region/liberty setup to test it?)
If a test just uses the JVM server for something else, and something fails in the test for some other reason, does the test need to be able to decide whether to collect/not collect JVM server+liberty diagnostics in the event of a failure ?
Seems to me that this could be added to a try...catch block within the test around the bits you exercise liberty with.
Talking to @ayushikumari3, we're happy with just using the existing saveToResultsArchive
method, rather than gathering diagnostics right now. We'll need the function to issue a PERFORM JVMSERVER ... command at some point, but it's not blocking (or could be issued via CEMT/CECI managers).
I think we'll be happy to look to enhancing the IJvmserver manager with this at some point in the future.
OK. We'll assign this story a low priority and leave on the backlog for now then. Thanks.
I believe we previously got gatherDiagnostics via the script directly in case the CICS Terminal locked up.
This issue is duplicated internally. The CICS team will work to resolve this themselves if it is an issue and we will contribute the fix back.
You can close this issue if you're happy with this.
Story
As a tester writing a test using the cics resources manager, if I have a JVM server resource, and the test fails, I want to run the JVM gather diagnostics script on USS to gather diagnostics for the JVM server, then either move that file to an archive on zos or adding it to the archived artifacts in Galasa, so I have the information available to download and browse through later.
Background