-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payara6: failing integration tests #9457
Comments
I probably need to do the rebase again. Something went sideways during the merge. |
Oliver created his squeaky clean Payara 6 branch and:
|
Oliver updated his branch but these last two runs failed before the API tests could be executed: |
@donsizemore and I talked about this. The API test suite is partially executing and this is flagged as a failure. This means the report never gets pushed so we have to try to figure out which API tests failed from the console log. It's hard to read the errors from the console log. Here's a quick one liner that got me closer to being able to read them:
I'm pretty sure the same tests are failing. |
@pdurbin well, the API test suite is fully executing, but we set |
Sized, labeled, and moved to Sprint Ready as per conversation with @scolapasta |
We're definitely suffering from problem related to the SWORD API that we saw with the last attempted Payara 6 upgrade. Here's the commit I put in last time: d86e220 I basically flagged it as an incompatible change:
Here are some comments I had added: // Under Payara 5 we could send "Content-Disposition: filename=example.zip" Here's my original writeup of the problem and the solution above: #8305 (comment) I'll look around for any more new information but we might have to simply accept this backward incompatibility. |
As I mentioned in Slack, I'm no longer sure what's going on.
Here are the results from the Payara 6 branch as of 26e66d8. Notice that there are a lot of 500 errors. If these 500 errors are due to Payara falling over, we might see different tests fail on a subsequent run. From https://github.com/pdurbin/dataverse-api-test-runner/actions/runs/5659573350/job/15333705090 [INFO] Results: Error: DatasetsIT.testRestrictFileExportDdi:2331 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFileTermsOfUseAndAccess:2889 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFilesWORequestAccess:2960 Expected status code <409> doesn't match actual status code <400>. Error: DataversesIT.testMalformedFacetQueryString:289 Error: DownloadFilesIT.downloadAllFilesRestricted:261 Expected status code <200> doesn't match actual status code <400>. Error: HarvestingClientsIT.testHarvestingClientRun:234 Last harvest not reported a success (took 0 seconds) expected: but was: Error: MakeDataCountApiIT.testMakeDataCountGetMetric:61 Expected status code <200> doesn't match actual status code <400>. Error: SearchIT.testGeospatialSearch:1233 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testGeospatialSearchInvalid:1274 Expected status code <400> doesn't match actual status code <500>. Error: SearchIT.testIdentifier:753 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testNestedSubtree:801 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testSubtreePermissions:987 Expected status code <200> doesn't match actual status code <500>. Error: Errors: Update, here another GitHub Actions run, from https://github.com/pdurbin/dataverse-api-test-runner/actions/runs/5660040551/job/15334873565 [INFO] Results: Error: DatasetsIT.testRestrictFileExportDdi:2331 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFileTermsOfUseAndAccess:2889 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFilesWORequestAccess:2960 Expected status code <409> doesn't match actual status code <400>. Error: DataversesIT.testMalformedFacetQueryString:289 Error: DownloadFilesIT.downloadAllFilesRestricted:261 Expected status code <200> doesn't match actual status code <400>. Error: HarvestingClientsIT.testHarvestingClientRun:234 Last harvest not reported a success (took 0 seconds) expected: but was: Error: MakeDataCountApiIT.testMakeDataCountGetMetric:61 Expected status code <200> doesn't match actual status code <400>. Error: SearchIT.testGeospatialSearch:1233 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testGeospatialSearchInvalid:1274 Expected status code <400> doesn't match actual status code <500>. Error: SearchIT.testIdentifier:753 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testNestedSubtree:801 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testSubtreePermissions:987 Expected status code <200> doesn't match actual status code <500>. Error: Errors: |
For kicks I tried running the entire API test suite against Payara 6 running on my home laptop (no Docker). Surprisingly, only one test failed! [INFO] ... and it turns out that test is likely due to some config that we should document. For now, see here:
But what does that mean? Is Jenkins wrong? 😬 |
Jenkins may well be wrong. Note that, in contrast, I can run the (passing) integration test suite on RHEL9 instead of RHEL8, and get some handful of test failures. Storage, system libraries, CPU/RAM seem to affect results. |
I just ran the tests on the "develop" branch (04385e7) and I'm seeing very similar failures from the GitHub Actions environment (see below). From https://github.com/pdurbin/dataverse-api-test-runner/actions/runs/5663434708/job/15345161727 [INFO] Results: Error: DatasetsIT.testRestrictFileExportDdi:2396 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFileTermsOfUseAndAccess:2954 Expected status code <200> doesn't match actual status code <400>. Error: DatasetsIT.testRestrictFilesWORequestAccess:3025 Expected status code <409> doesn't match actual status code <400>. Error: DataversesIT.testMalformedFacetQueryString:291 Error: DownloadFilesIT.downloadAllFilesRestricted:261 Expected status code <200> doesn't match actual status code <400>. Error: HarvestingClientsIT.testHarvestingClientRun:234 Last harvest not reported a success (took 0 seconds) expected: but was: Error: MakeDataCountApiIT.testMakeDataCountGetMetric:61 Expected status code <200> doesn't match actual status code <400>. Error: SearchIT.testGeospatialSearch:1234 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testGeospatialSearchInvalid:1275 Expected status code <400> doesn't match actual status code <500>. Error: SearchIT.testIdentifier:754 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testNestedSubtree:802 Expected status code <200> doesn't match actual status code <500>. Error: SearchIT.testSubtreePermissions:988 Expected status code <200> doesn't match actual status code <500>. Error: Errors: |
Lots of activity today. The bottom line is that for whatever reason Jenkins ALMOST got all the tests to run. In https://jenkins.dataverse.org/job/IQSS-Dataverse-Payara6/51/ we saw a single failure, which should be fixed by this PR: So I merged the latest from develop into #9685, resolved merge conflicts, etc. But then Payara wouldn't start due to this issue: So I also pushed the suggested fix into the Payara 6 branch: da5193f Will Jenkins pass this time?!? Stay tuned! This is the job to watch: https://jenkins.dataverse.org/job/IQSS-Dataverse-Payara6/52/ Why was it failing before? That's unknown. 🤔 @donsizemore did spin me up my own Payara 6 server and I got the full API test suite to run there. Again, now we need to make sure Jenkins is happy. If Jenkins ain't happy, ain't nobody happy! |
I was wrong about this. The SWORD fix I mentioned above is already in the Payara 6 branch under this commit: 89182c1 I like Oliver's idea in #9685 - "Should we preserve backward compatibility of the SWORD API by inserting attachment; for the user if it isn't supplied?" I'm planning on poking around with this. |
@pdurbin Promise you won't kill me: in that branch I had bumped the AWS AMI to Rocky 8.8, meaning to merge it to develop. Aside from that difference in minor release (though binary compatibility is a tenet of RHEL), the only other difference is that Ansible didn't automatically fire off the test suite on your server - giving garbage collection a chance to do its thing. If Payara6#52 had trouble (I'll check tomorrow) I can bump the AMI, but... we're really close! |
Yes! Very close. I think all the API tests passed but the next (hopefully small) hurdle is to get the job to not error out. I opened this issue: |
Good news! The last two builds succeeded with all API tests passing: ![]() I'm especially glad about the second build because I pushed a fix to the Payara 6 branch to keep SWORD working as-is. The details are in 0221006 but I reverted the workaround and put in what I think is a better fix. We can talk about it more as we review that branch/PR. |
I'm also testing the Payara 6 branch by manually running a job at https://github.com/pdurbin/dataverse-api-test-runner/actions/workflows/payara6.yml It uses GitHub Actions to test Dataverse running in Docker. Since both Jenkins and GitHub Actions are showing passing tests, I'm closing this issue. |
Current state of integration tests on Payara 6.2023.2 running @poikilotherm's Payara6 branch:
The text was updated successfully, but these errors were encountered: