Skip to content

Commit

Permalink
feat: minor naming tweaks and docs for integs
Browse files Browse the repository at this point in the history
ref #401 & #424

Signed-off-by: Jim Crossley <jim@crossleys.org>
  • Loading branch information
jcrossley3 committed Aug 23, 2023
1 parent 777b4ec commit 3e925cb
Show file tree
Hide file tree
Showing 3 changed files with 100 additions and 10 deletions.
5 changes: 4 additions & 1 deletion DEVELOPING.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,10 @@ brew install protobuf

## Integration tests

Trustification comes with a set of integration tests that you can run assuming dependent services are launched with the above compose configuration:
Trustification comes with a set of [integration-tests/](integration
tests) that you can run after the required services defined in the
[deploy/compose/compose.yaml](default compose script) are up and
running. Once they're up, run the tests like so:

```shell
cargo test -p integration-tests
Expand Down
76 changes: 76 additions & 0 deletions integration-tests/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# Integration tests

By default, these tests expect the services defined in the
[../deploy/compose/compose.yaml](default compose script) -- MinIO,
Kafka, and Keycloak -- to be up and running. Once they're ready, run
the tests like so:

```shell
cargo test -p integration-tests
```

To see more detailed output:

```shell
RUST_LOG=info cargo test -p integration-tests -- --nocapture
```

The tests do not require Trustification itself to be running. Each
test will start whatever services it requires and then shut them down
when the test completes. It is possible, however, to override that
default behavior and direct the integration tests at a particular
Trustification instance.

## Testing a remote Trustification instance

Setting the `TRUST_URL` environment variable to the URL for a remote
trustification server triggers the integs to be run against it.

If it's set, other env vars will be required:
* `TRUST_ID` -- a client id with *manager* authorization, i.e. "write" permissions
* `TRUST_SECRET` -- the secret associated with `TRUST_ID`
* `TRUST_USER_ID` -- (optional, defaults to `TRUST_ID`) a client id
for a non-privileged user, i.e. "read-only"
* `TRUST_USER_SECRET` -- (optional, defaults to `TRUST_SECRET`) the
secret associated with `TRUST_USER_ID`
* `KAFKA_BOOTSTRAP_SERVERS` -- (optional) if set, its value will be
used to configure the event bus required by some of the
tests. Otherwise, [https://aws.amazon.com/sqs/](SQS) is assumed
and valid AWS credentials will be required.

Some examples might be nice. Let's assume you're running a local
instance of trustification like so:

```shell
docker compose -f deploy/compose/compose-trustification.yaml up
```

The default URL for that instance is http://localhost:8084 so we'll
point the integs there. We first need to set `KAFKA_BOOTSTRAP_SERVERS`
for those tests that expect events.

```shell
export KAFKA_BOOTSTRAP_SERVERS=localhost:9092
```

To run all the tests:

```shell
TRUST_URL=http://localhost:8084 \
TRUST_ID=testing-manager \
TRUST_SECRET=R8A6KFeyxJsMDBhjfHbpZTIF0GWt43HP \
TRUST_USER_ID=testing-user \
TRUST_USER_SECRET=ZVzq9AMOVUdMY1lSohpx1jI3aW56QDPS \
cargo test -p integration-tests
```

If you limit which tests run, you don't need to provide all the
variables. For example, to run just the `bombastic_search` test, only
these are needed:

```shell
TRUST_URL=http://localhost:8084 \
TRUST_ID=testing-manager \
TRUST_SECRET=R8A6KFeyxJsMDBhjfHbpZTIF0GWt43HP \
cargo test -p integration-tests bombastic_search
```
29 changes: 20 additions & 9 deletions integration-tests/src/config.rs
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
use std::env::VarError;

use reqwest::Url;
use serde_json::Value;
use trustification_event_bus::{EventBusConfig, EventBusType};
Expand All @@ -10,9 +12,10 @@ pub struct Config {
pub bombastic: Option<Url>,
pub vexination: Option<Url>,
issuer: String,
user: String,
manager: String,
secret: String,
mgr_id: String,
mgr_secret: String,
user_id: Option<String>,
user_secret: Option<String>,
}

impl Config {
Expand All @@ -35,20 +38,28 @@ impl Config {
bombastic: endpoints["bombastic"].as_str().map(Url::parse).unwrap().ok(),
vexination: endpoints["vexination"].as_str().map(Url::parse).unwrap().ok(),
issuer: endpoints["oidc"]["issuer"].as_str().unwrap().to_string(),
user: std::env::var("TRUST_USER_ID").expect("TRUST_USER_ID is required"),
manager: std::env::var("TRUST_MANAGER_ID").expect("TRUST_MANAGER_ID is required"),
secret: std::env::var("TRUST_SECRET").expect("TRUST_SECRET is required"),
mgr_id: std::env::var("TRUST_ID").expect("TRUST_ID is required"),
mgr_secret: std::env::var("TRUST_SECRET").expect("TRUST_SECRET is required"),
user_id: std::env::var("TRUST_USER_ID").ok(),
user_secret: std::env::var("TRUST_USER_SECRET").ok(),
}
}
_ => Config::default(),
Err(VarError::NotPresent) => Config::default(),
Err(e) => panic!("Unexpected error reading environment variable: {e}"),
}
}

pub async fn provider(&self) -> ProviderContext {
// For convenience, we default the user's id/secret to that of
// the manager, but this will break any tests that require a
// user's role to be less authorized than a manager.
let user_id = self.user_id.as_ref().unwrap_or(&self.mgr_id);
let user_secret = self.user_secret.as_ref().unwrap_or(&self.mgr_secret);

match self.spog {
Some(_) => ProviderContext {
provider_user: create_provider(&self.user, &self.secret, &self.issuer).await,
provider_manager: create_provider(&self.manager, &self.secret, &self.issuer).await,
provider_user: create_provider(user_id, user_secret, &self.issuer).await,
provider_manager: create_provider(&self.mgr_id, &self.mgr_secret, &self.issuer).await,
},
_ => create_provider_context().await,
}
Expand Down

0 comments on commit 3e925cb

Please sign in to comment.