Test CDA and database compatibility across runtime versions - #298
Conversation
ac1d854 to
da156ba
Compare
da156ba to
df6e646
Compare
|
krowvin
left a comment
krowvin
left a comment
There was a problem hiding this comment.
Few thoughts I had while making this PR
| traefik: | ||
| condition: service_healthy | ||
| image: ${CWMS_DATA_API_IMAGE:-ghcr.io/usace/cwms-data-api:latest} | ||
| image: ${CWMS_DATA_API_IMAGE:-ghcr.io/usace/cwms-data-api:develop-2026.05.30} |
There was a problem hiding this comment.
I still am not 100% sure on if we want to lock the versions in.
If we add a new parameter, for example, we would then need to make sure this gets updated to match.
And it maybe confusing to determine that was the cause/need from the logs alone.
cwmsjs is getting around this by being generated as CDA updates
There was a problem hiding this comment.
no and definitely should not be that version. that is behind what is in production.
There was a problem hiding this comment.
I'm not sure if the latest image is getting updated frequent enough? @MikeNeilson
Should we target the current production version 2026.05.12-f? If a develop version is targeted for the tests then things might pass that are not on prod yet.
I was trying to target something around this.
There was a problem hiding this comment.
develop-nightly should be getting updated nightly.
Build should be a matrix. Preferably with 3 entries per database and cda, the latest, what's deployed in prod, and what's deployed in test.
This makes sure the client will behave correctly in each environment. We do this for CDA against the the database versions.
NOTE: that does mean the matrix is two variables (CDA + Database) so 3x3, does get a bit large but that's just testing, it's a lot.
| @@ -0,0 +1,3 @@ | |||
| AUTH_RE_ENABLE_NON_HASH_KEY_SUPPORT=true | |||
There was a problem hiding this comment.
This should make it so we don't need to hash the keys locally and our old keys keep working
There was a problem hiding this comment.
It is easy to add the hashed keys I will set that up.
There was a problem hiding this comment.
Want to PR off this or make a separate PR for that?
If you are busy we could merge this in now so the old keys keep working then your PR can use the new ones?
|
@krowvin check what is still needed with my changes that I just merged in main. |
| traefik: | ||
| condition: service_healthy | ||
| image: ${CWMS_DATA_API_IMAGE:-ghcr.io/usace/cwms-data-api:latest} | ||
| image: ${CWMS_DATA_API_IMAGE:-ghcr.io/usace/cwms-data-api:develop-2026.05.30} |
There was a problem hiding this comment.
arguably the default here should be either develop or what's in prod. But the test matrix should override it for testing. and it should be documented for developers if they want to target something specific for some reason.
krowvin
changed the title
|
3 participants
Reconciles this branch with current
main, including Eric's #300 hashed API-key fixtures, test fixes, and Python 3.9/3.13 integration coverage. Removes this PR's legacy plaintext-key feature override and retains the cascade-delete cleanup for timeseries groups.Addresses Mike's CI feedback by testing CDA and database versions as independent matrix axes: latest development, production release, and test release. With both Python versions, that produces 18 integration jobs. The schema installer matches the selected database tag, backend startup waits for health, and Python caches use the resolved interpreter version. Local CDA defaults to
develop-nightly;CONTRIBUTING.mddocuments all three image overrides and the matrix pins.Current pins: CDA
develop-nightly,2026.05.12-i,2026.08.31-testd; database/schema installerlatest-dev,26.02.17,26.07.16-RC02. Production CDA was verified from its public OpenAPI document on September 8. The test CDA pin follows the latest published test release, and database pins follow CDA's own release/next-release CI lanes; the deployed test/database versions could not be independently confirmed. All image references exist in GHCR.Validation:
AI tools used.