Swap to using environment variables for hard coded certs

[epag]

He currently have hard coded cert names in our broker

https://github.com/NOAA-OWP/wres/blob/bc993975a9ce41be6d0dc9eb54daa36d8ecb4e1c/wres-broker/nonsrc/rabbitmq.conf#L10-L23

Also there is this hard coded pass for our trust store. Which doesn't really do anything but for craftmanship should be extracted as well ( think it also shows up in a test file as well)

https://github.com/NOAA-OWP/wres/blob/bc993975a9ce41be6d0dc9eb54daa36d8ecb4e1c/wres-system/src/wres/system/SSLStuffThatTrustsOneCertificate.java#L111-L115

https://github.com/NOAA-OWP/wres/blob/bc993975a9ce41be6d0dc9eb54daa36d8ecb4e1c/wres-messages/src/main/java/wres/messages/BrokerHelper.java#L171-L172

[james-d-brown]

Also, minor aside, should not log AND throw an exception, one or the other:

catch ( IllegalStateException ise )
        {
            LOGGER.error( "Failed to initialize the broker connection factory; message: " + ise.getMessage()
                          + ". Aborting WresJob static block.",
                          ise );
            throw ise;
        }

[james-d-brown]

Unsure why they are failing locally and not in our build environment, but also unsure why they should pass when this system property is not going to be available in the (unit) test environment. Anyway, all of WresJobTest fails locally for me, whether executed via gradle or in my ide test runner.

[HankHerr-NOAA]

The exception was not one added by me (at least for this ticket), but, if I'm in that code again, I can clean it up.

I'm running the build, now, on my laptop, which succeeded the last time I tried it a couple of days ago, even though Eclipse reports many errors. Go figure.

Hank

[HankHerr-NOAA]

Reproduced the error on my laptop,

Hank

[HankHerr-NOAA]

I'm not sure why it would have succeed with the pull request, unless the wres-tasker unit tests are not called.

Hank

[epag]

The tests run should be a carbon copy of what we used to do in Jenkins. Maybe that is only running a subset. I can create a ticket to look at that and add them into the PR process if needed

[james-d-brown]

No idea, but we need to look into that too. All unit tests should be executed and I doubt there is any special github config to call a subset of tests, so it is more likely something about the build environment. I only hesitate because I cannot see how those tests could possibly pass when they depend on a system property.

[epag]

Created a ticket to look into it, I guess until then we just need to make sure the thing build locally before a PR (which is a reasonable expectation to have, but will still add more precaution in #309)

[james-d-brown]

I doubt you are doing anything special, it will be something like gradlew distZip testCodeCoverageReport javadoc, which will build and run all the unit tests and create a code coverage report, as well as building the javadoc. Could be some issue related to incremental builds, perhaps, but I doubt it because the code that is failing was explicitly just changed.

[HankHerr-NOAA]

It appears as though WresJobTest.java is creating the needed .p12 file on-the-fly in a temporary location, so all I need to do is export these system properties as part of the unit test:

        System.setProperty(  Tasker.PATH_TO_CLIENT_P12_PNAME, WresJobTest.tempDir.toString() + "/" + WresJobTest.P12_FILE_NAME );
        System.setProperty(  Tasker.PASSWORD_TO_CLIENT_P12, "wres-tasker-passphrase" );

Testing that idea now,

Hank

[HankHerr-NOAA]

If I can figure out how to revisit the pull request, I can probably take a look at the last unit test log and search for WresJobTest. Looking,

Hank

[HankHerr-NOAA]

This horrible looking URL takes you to raw output that shows that at least some tests are run, like DataSourceTest:

https://productionresultssa10.blob.core.windows.net/actions-results/1ddd41c2-5562-41e4-97fc-b3cb5abe5b68/workflow-job-run-ca395085-040a-526b-2ce8-bdc85f692774/logs/job/job-logs.txt?rsct=text%2Fplain&se=2024-09-06T17%3A43%3A39Z&sig=K%2FSexezhcwYY93dPzj36merJiesTuvKaoCMcZWbveDg%3D&ske=2024-09-07T02%3A23%3A36Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2024-09-06T14%3A23%3A36Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2024-05-04&sp=r&spr=https&sr=b&st=2024-09-06T17%3A33%3A34Z&sv=2024-05-04

However, when I try to find WresJobTest using my browser, nothing is found.

Hank

[HankHerr-NOAA]

JobResultTest also isn't found, though I can find "wres-tasker". I might need Evan's help figuring this one out.

The code change I mentioned does seem to work for gradle build run within my Eclipse. I'm going to test moving the system property setting to the setup method so that I only need to call it once instead of once per test.

Hank

[HankHerr-NOAA]

On a whim, I looked for the WresEvaluationProcessorTest from wres-worker and couldn't find it.

More generally, if I check that output for ":test", I can click through and see that at the least wres-tasker:test and wres-worker:test do not appear. I don't know if there are others missing. For example, wres-vis and wres-writing are both there. Why is wres-tasker and wres-worker being left out?

FYI... I'm having problems figuring out how to force my Eclipse run of gradle build to run ALL tests. It only wants to run tests for updated code. I want to see a full build in order to convince myself I've fixed the problem.

Hank

[HankHerr-NOAA]

I found the build clean Gradle task, ran that, and then ran the build again, and it seems to be doing what I want. Will report back. If it succeeds, since I'm not familiar enough with Eclipse, I'm going to create the branch on Linux, port the code over, push, and then create the pull request.

I really need to fix my Eclipse.

Hank

[HankHerr-NOAA]

A full build seems to work with my changes. I'm ready to push the code.

Since my github_296 branch is still alive, I'm going to push to that branch to hopefully create a new pull request. I'm going to re-open this ticket so that I can "fix" it with that pull request.

Let's see if that works,

Hank

[HankHerr-NOAA]

Just marked this in progress, since an issue was discovered with my fix. The next pull request should close this ticket, again, and then I'll move it to UAT as a reminder to handle the environment variables when deploying.

Hank

[HankHerr-NOAA]

Finally noticed Evan's ticket to look in the unit tests. Cool.

Trying to track down where unit test results are reported for my push to the branch.

Hank

[HankHerr-NOAA]

Found it:

https://github.com/NOAA-OWP/wres/actions/runs/10743092061

I'll wait to see if the build succeeds before creating the pull request, though, again, the impacted test is likely not even going to be run.

Hank

[HankHerr-NOAA]

Pull request created and waiting for checks to pass before merging.

Hank

[HankHerr-NOAA]

James:

The change is merged. If you have a chance, please pull the latest and try to build again.

Thanks,

Hank

[james-d-brown]

Thanks, build now succeeds locally.

[james-d-brown]

Aside: it is best practice to build and run the unit tests and, ideally, the system tests locally before pushing. Appreciate there are various layers here and it is a confidence building exercise to some degree, but minimum should be build and unit tests and system tests unless you are really confident that the changes don't impact them (e.g., javadoc).

[james-d-brown]

Hey ho. I've broken the build before myself, and the consequences are reduced now we are branching on every issue. Just need to work out why some packages are apparently not being unit tested in our build environment - very odd, because I expect Evan pretty much copy/pasted the gradle build command from jenkins, unless there is some github wrapper foo that handled that and is going awry.

[james-d-brown]

Anyway, I'm off now. Back at the end of September. Have a great few weeks all!

[HankHerr-NOAA]

James:

I agree completely. The issue is that I can't run the unit tests on Linux, and, since testing required deploying to the -dev COWRES, I was pretty much stuck with Linux development (not to mention my Eclipse issues). Hence, I had to hope that I would not break the unit tests. Unfortunately, I did.

Once I can get the unit tests running in Linux, again, I'll be able to better follow the appropriate life cycle, and, at the least, run those unit tests. In this case, system tests should not have been impacted, but I probably could have run them before hand. Regardless, it wouldn't have helped with the unit test issues.

Thanks and try to relax during your time away!

Hank

[HankHerr-NOAA]

I'm removing/closing/whatever the github_296 branch.

Hank

[HankHerr-NOAA]

Moving this to UAT.

[HankHerr-NOAA]

This was in UAT as a reminder to setup the .env properly in staging. That was done and a checkbox was created to the deployment ticket for both staging and production, so I think we are covered as far as reminders.

The staging COWRES looks good using the environment variables, so I'm marking this ticket as done.

Hank