oscerd opened a new pull request, #29818: URL: https://github.com/apache/camel/pull/29818
## Description The integration test of camel-google-storage (`ComplexIT`) ran only with `GOOGLE_APPLICATION_CREDENTIALS` set for a real project. The AWS test-infra runs its local services on Floci (#23404), and the Azure one on Floci AZ (#29229 and the PRs after it). [Floci GCP](https://github.com/floci-io/floci-gcp) (MIT) is the Google Cloud emulator of the same family: one container serves the gRPC and REST APIs of Cloud Storage, Pub/Sub, Firestore, Secret Manager, BigQuery and more on port 4588. This PR brings it to the Google test-infra, starting with Cloud Storage: - adds a `camel-test-infra-google-common` module with `FlociGcpContainer`, which waits for `/health` and gives the address of the emulator. Its image is the `google.container` key of the module's `container.properties` (`mirror.gcr.io/floci/floci-gcp:0.12.0`; the upgrade check skips the `latest`, `nightly` and `-compat` tags); - adds a `camel-test-infra-google-storage` module: a local Cloud Storage service on Floci GCP (`camel infra run google storage`), which gives its endpoint and a project id (`test-project`: Floci GCP accepts any), and a remote one for a real project, which the clients reach with the application default credentials; - runs `ComplexIT` against it: on Floci GCP by default, and with `-Dgoogle.instance.type=remote` against the project of the application default credentials, as before. The endpoints no longer pass `serviceAccountKey=file:$GOOGLE_APPLICATION_CREDENTIALS`, which the default credentials read anyway; - on Floci GCP, the test binds a client for the emulator, which the endpoints take as their `storageClient`. Its credentials are the ones of a service account key that the test makes, because the `createDownloadLink` operation signs its links, which no credentials cannot do; Floci GCP gives an access token to any service account at its `/token` address; - the test waits for its mocks instead of sleeping 10 seconds, and gives each of the three uploaded objects its own name and stream: they had random names, which could collide, and shared one stream, which the first upload read to the end; - skips the integration tests on ppc64le and s390x, where the Floci GCP image is not available; - regenerates the test-infra metadata: `google storage` at version `0.12.0`. Pub/Sub stays on the Cloud SDK emulator for now (CAMEL-26614): on Floci GCP 0.12.0, `MessageOrderingIT` fails, because the streaming pull responses of Floci GCP do not carry the message ordering flag of the subscription, which the Java client needs to deliver the messages of an ordering key one at a time. ## Testing - `ComplexIT` passes against Floci GCP 0.12.0, in 3 runs in a row; the 70 unit tests pass. - With `-Dgoogle.instance.type=remote`, no container starts and the endpoints take the application default credentials (checked without any: the test fails on `Your default credentials were not found`). - Full reactor build; the test-infra metadata is regenerated. _Claude Code on behalf of Andrea Cosentino_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
