services/galexie: add integration tests for S3 storage.#5749
services/galexie: add integration tests for S3 storage.#5749tamirms merged 10 commits intostellar:masterfrom
Conversation
eb86f15 to
0bc05d1
Compare
|
@overcat we've been a bit busy with the Protocol 23 release but we'll review this soon. Thanks! |
It's okay, this PR is not urgent. |
urvisavla
left a comment
There was a problem hiding this comment.
Great work integrating the S3 tests into the existing framework. The PR looks good.
|
@overcat this looks great! could you add one more test case to the integration tests? I don't think we have any coverage which exercises the code path where we receive a precondition failed error upon trying to insert a file that already exists. I think the following test case should exercise that path:
In step (3) galexie should try to insert ledger files 8, 9, and 10. But, it should receive a precondition failed error from AWS and handle that error by skipping over to the next files |
Hi @tamirms, I would like the existing TestAppend test to include this scenario. Theoretically, it is best if we can ensure that the object has not changed, but the current datastore interface does not provide this capability. If necessary, we can add a function to the datastore to return the object's identifier. |
sure, that sounds good!
I'm not sure what would be the equivalent of that for GCS. Alternatively, you could return the last modified timestamp of the object. I believe that is available for both GCS and S3 |
By this I'm assuming you mean that the object in the datastore is the same as the one we're attempting to upload. We could definitely check for that, but I'm not sure what we’d do with that information beyond just logging it, unless you're suggesting we go ahead and overwrite the object (upload without preconditions) in such a case. |
|
Hey @tamirms, I think 6804884 might be what you're looking for. Let me know if I'm on the right track so I can get those unit tests for |
@overcat that looks good to me! |
There was a problem hiding this comment.
Pull Request Overview
This PR adds comprehensive integration tests for S3 storage backend support in Galexie, complementing the existing GCS integration tests. The changes enable testing both GCS and S3 datastores to ensure feature parity and proper functionality across different cloud storage providers.
- Adds
GetFileLastModifiedmethod to the DataStore interface and all implementations - Extends integration test suite to support both GCS and S3 storage backends with LocalStack
- Updates CI workflows to run tests against both storage types
Reviewed Changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| support/datastore/datastore.go | Adds GetFileLastModified method to DataStore interface |
| support/datastore/s3_datastore.go | Implements GetFileLastModified and refactors to use HeadObject helper |
| support/datastore/gcs_datastore.go | Implements GetFileLastModified and refactors to use GetFileAttrs helper |
| support/datastore/mocks.go | Adds mock implementation for GetFileLastModified method |
| support/datastore/s3_datastore_test.go | Adds lastModified field to mock objects and tests for GetFileLastModified |
| support/datastore/gcs_test.go | Adds test for GetFileLastModified functionality |
| services/galexie/internal/integration_test.go | Splits integration tests into GCS and S3 suites with LocalStack support |
| services/galexie/internal/test/integration_config_template.toml | Adds S3-specific configuration parameters |
| services/galexie/DEVELOPER_GUIDE.md | Updates documentation to reflect separate test suites |
| .github/workflows/galexie.yml | Updates CI to run tests for both GCS and S3 storage types |
| .github/workflows/galexie-release.yml | Updates release workflow to test both storage backends |
|
@overcat sorry, you're correct! I don't know how I missed that code. Could you also add similar logic to Once that's done I will approve and merge the PR |
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
CHANGELOG.mdwithin the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
This is the follow-up PR for #5748. Let's merge #5748 first, and then we'll handle this PR.
Why
See #5748
Known limitations
N/A