Integration tests executed on a real deployment as part of the CICD - Environments #1230
Assignees
Labels
Comments
petrkalos
added a commit
that referenced
this issue
Jun 19, 2024
### Feature or Bugfix
Feature
### Detail
- small refactor of existing test code
- add some environment queries with polling logic
- add environment fixtures with safe create and delete
- run tests in parallel
- new testdata format...
``` {
"users": {
"testUserTenant": {
"username": "testUserTenant",
"password": "...",
"groups": [
"DAAdministrators"
]
}
"envs": {
"session_env1": {
"accountId": "123",
"region": "eu-central-1"
}
}
}
### Relates
#1230
### Security
Please answer the questions below briefly where applicable, or write
`N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).
- Does this PR introduce or modify any input fields or queries - this
includes
fetching data from storage outside the application (e.g. a database, an
S3 bucket)?
- Is the input sanitized?
- What precautions are you taking before deserializing the data you
consume?
- Is injection prevented by parametrizing queries?
- Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires
authorization?
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
- Are you logging failed auth attempts?
- Are you using or adding any cryptographic features?
- Do you use a standard proven implementations?
- Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users?
- Have you used the least-privilege principle? How?
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
petrkalos
added a commit
that referenced
this issue
Jun 21, 2024
) ### Feature or Bugfix Feature ### Detail Currently data.all reads the config that is commited to the root directory of the repo. In this PR we allow customers to customize the params as defined in the config.json (or completely overwrite it) using an SSM parameter (`/datall/{ENV}/configjson`). The new workflow will be as follows 1. Read the `config.json` (as always) 2. Read the configjson SSM param and merge it with the contents of config.json (essentially overwriting the specified params) This is useful for the following cases... * Running a CI/CD pipeline directly from GitHub repo and want to customize the behaviour * Running multiple stages/envs (dev, uat, prod etc) and want to customize them separately ### Relates - #1230 - #1136 ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
|
In #1334 some basic tests that create/delete/modify an environment were added but more should be added to cover the most commonly used functionality around environments |
Required tests for basic coverageFor fresh deploymentsFor each of the following API calls we need to test authorized and unauthorized scenarios as well as all possible configurations (e.g. test delete environment when there are existing resources)
For backwards compatibility
@petrkalos can you check the items that are already implemented in #1334? |
|
Completed! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description in #1220.
This issue is to track the progress for the
Environmentsmodule.It has its complications because we need to work with real AWS accounts that need to be bootstrapped and trusting the real deployment account.
Design will follow
The text was updated successfully, but these errors were encountered: