Follow-up from PR #117 (which fixed the .only/console.log issues from #66).
The BYO S3 integration suite in s3-api/src/tests/byoS3.test.ts now correctly skips itself when AWS credentials aren't configured, which is exactly right for the current no-CI state of the repo. But worth thinking ahead: if/when real AWS credentials get added as CI secrets, a few of these tests mutate state that isn't reset between runs:
renames a file to another renames parser.py → parser_n.py under a fixed path. Run it twice and the second run has nothing to rename.renames a folder to another renames users/demo1/ → users/exefiles/ — same problem.
Two runs in a row (or two concurrent CI jobs) would step on each other. Worth deciding before wiring up real creds: do we add setup/teardown to reset fixture state each run, generate unique keys per run (e.g. a UUID suffix), or something else?
Not urgent — just don't want it to get lost.
Follow-up from PR #117 (which fixed the
.only/console.logissues from #66).The BYO S3 integration suite in
s3-api/src/tests/byoS3.test.tsnow correctly skips itself when AWS credentials aren't configured, which is exactly right for the current no-CI state of the repo. But worth thinking ahead: if/when real AWS credentials get added as CI secrets, a few of these tests mutate state that isn't reset between runs:renames a file to anotherrenamesparser.py→parser_n.pyunder a fixed path. Run it twice and the second run has nothing to rename.renames a folder to anotherrenamesusers/demo1/→users/exefiles/— same problem.Two runs in a row (or two concurrent CI jobs) would step on each other. Worth deciding before wiring up real creds: do we add setup/teardown to reset fixture state each run, generate unique keys per run (e.g. a UUID suffix), or something else?
Not urgent — just don't want it to get lost.