{"id":26256509,"url":"https://github.com/netcracker/qubership-docker-integration-tests","last_synced_at":"2026-01-30T11:48:11.774Z","repository":{"id":269042688,"uuid":"887166159","full_name":"Netcracker/qubership-docker-integration-tests","owner":"Netcracker","description":null,"archived":false,"fork":false,"pushed_at":"2026-01-14T15:06:58.000Z","size":227,"stargazers_count":1,"open_issues_count":12,"forks_count":5,"subscribers_count":7,"default_branch":"main","last_synced_at":"2026-01-14T18:57:12.696Z","etag":null,"topics":["qubership-infra","saqs"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Netcracker.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE-OF-CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-11-12T09:28:34.000Z","updated_at":"2026-01-06T13:05:07.000Z","dependencies_parsed_at":"2026-01-07T14:00:54.602Z","dependency_job_id":null,"html_url":"https://github.com/Netcracker/qubership-docker-integration-tests","commit_stats":null,"previous_names":["netcracker/qubership-docker-integration-tests"],"tags_count":15,"template":false,"template_full_name":null,"purl":"pkg:github/Netcracker/qubership-docker-integration-tests","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Netcracker%2Fqubership-docker-integration-tests","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Netcracker%2Fqubership-docker-integration-tests/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Netcracker%2Fqubership-docker-integration-tests/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Netcracker%2Fqubership-docker-integration-tests/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Netcracker","download_url":"https://codeload.github.com/Netcracker/qubership-docker-integration-tests/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Netcracker%2Fqubership-docker-integration-tests/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28912008,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-30T08:15:08.179Z","status":"ssl_error","status_checked_at":"2026-01-30T08:14:31.507Z","response_time":66,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["qubership-infra","saqs"],"created_at":"2025-03-13T20:18:21.234Z","updated_at":"2026-01-30T11:48:11.759Z","avatar_url":"https://github.com/Netcracker.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Introduction\n\nThe `Docker Integration Tests` (aka `BDI`) is image for integration tests.\nSupposed that this image will not be used to execute integration tests directly\nbut real images for integration tests will use this image as basic\n(`FROM` command in the particular docker file). BDI builds some `sandbox` which\nincludes `python` interpreter, Robot Framework, some useful tools such as\n`bash`, `shadow`, `vim`, `rsync`, `ttyd`, common custom Robot Framework libraries\n(for example, `PlatformLibrary`) and customized docker entry point script.\n\n* [Introduction](#introduction)\n  * [Pre-installed tools](#pre-installed-tools)\n  * [Library documentation](#library-documentation)\n  * [Docker Entry point Script](#docker-entry-point-script)\n    * [run-robot description](#run-robot-description)\n      * [`service checker script`](#service-checker-script)\n      * [`excluded tags resolver`](#excluded-tags-resolver)\n      * [`robot tests execution`](#robot-tests-execution)\n      * [`analyze results`](#analyze-results)\n      * [`write status`](#write-status)\n  * [Environment Variables](#environment-variables)\n\n## Pre-installed tools\n\nThe `Docker Integration Tests` contains the following pre-installed Linux tools:\n\n* `python` (version 3.10.13)\n* `bash`\n* `shadow`\n* `vim`\n* `rsync`\n* `ttyd`\n\n## Library documentation\n\n`PlatformLibrary` documentation is autogenerated by Robot Framework libdoc tool. It can be found\n[PlatformLibrary.html](/docs/library_documentation/PlatformLibrary.html).\n\nTo generate new doc you should navigate to current project repository and execute the following command:\n\n```bash\npython -m robot.libdoc PlatformLibrary.py PlatformLibrary.html\n```\n\nand move `PlatformLibrary.html` file to documentation directory.\n\n## Docker Entry point Script\n\nA docker entry point script is a script which will be executed after docker container is created.\nIf you override the image, its entry point script\nwill be executed by default. But if you override the entry point as well, your own entry point will be run.\nDocker Integration Tests contains simple and customized entry point script - `/docker-entrypoint.sh`\nwith the following command (possible `CMD` arguments):\n\n* `run-robot` is a default `CMD` command which executes Robot Framework test cases, can resolve\n* Robot Framework tags to be excluded, can create\n  `result.txt` file with parsed Robot Framework tests results in pretty format.\n  After tests execution `ttyd` tool is started.\n\n* `run-ttyd` command starts `ttyd` tool. `ttyd` is Web-console which rather useful for dev and troubleshooting purposes.\n\n* `custom` command executes custom bash script if this script's path is provided.\n* To provide custom script this script should exist within container\n  and environment variable `CUSTOM_ENTRYPOINT_SCRIPT` should contain path to the script.\n  Actually, `custom` command is equivalent to overriding the entry point\n  script but we recommend implementing custom script instead of entry point overriding.\n\nExample of equivalent console command:\n\n```bash\n/docker-entrypoint.sh run-robot\n```\n\nBelow is detailed description regarding `run-robot` command.\n\n### run-robot description\n\n`run-robot` command contains 4 customized steps.\n\n#### `service checker script`\n\nSometimes we want to make sure that \"tested\" service is ready for testing and start execution only for \"ready\" service.\nFor this purpose inheritor image should implement \"service checker script\" (python) which gives `timeout`\nargument in seconds (by default `timeout` is 300 second but can be overridden by `SERVICE_CHECKER_SCRIPT_TIMEOUT`\nenvironment variable) and checks if the service is ready. If the service is ready entry point script\ngoes to the next step. To specify \"service checker script\" `SERVICE_CHECKER_SCRIPT` environment variable should not\nbe empty and should contain path to custom python script.\nBy default, `SERVICE_CHECKER_SCRIPT` is empty and current entry point script step is skipped.\n\n#### `excluded tags resolver`\n\nSometimes some Robot Framework tests can not be executed in given configuration. For example, test should\ncheck `Elasticsearch` service but `elasticsearch` URL is not given and we want to skip this test.\nThe Robot Framework paradigm supposed that this case should be resolved by tag approach. We can point which\ntests should be skipped by its tags. For example, `robot -e my-excluded_tag ./tests`.\n\nDocker Integration Tests entry point script provides development approach to recognize which tests should be\nskipped before tests execution. Supposed that `.robot` files are contained some root folder (for, example `tests`).\n\n`robot_tags_resolver.py` script recursively bypasses all inner folder to look up all `tags_exclusion.py` modules.\nFor each found module `get_excluded_tags(environ)` function will be executed, where where environ is a list of\nenvironment variables. `get_excluded_tags` function should return list or dictionary of excluded tags.\n\nIf list is returned, all tags will be added to result set of excluded tags. If dictionary is returned, all keys\nwill be added to result set of excluded tags and the particular dictionary will update result dictionary\nwhich will be printed to console as some map where keys are excluded tags and values are reasons why these\ntags are excluded. Default tags resolver script is `robot_tags_resolver.py` but inheritor image can override it\nby `TAGS_RESOLVER_SCRIPT` environment variable which contains path to custom tags resolver script.\n\nTo skip excluded tags resolving process environment variable `IS_TAGS_RESOLVER_ENABLED`\nshould be `false` (it is `true` by default).\n\n#### `robot tests execution`\n\nThis step can not be skipped. It executes Robot Framework tests without excluded ones. If `TAGS` environment variable is\npresented only these tags will be executed. This is an example of specifying only `first` and `second` tests\nfrom `first`, `second` and `third`:\n\n```bash\nfirstORsecond\n```\n\nIf tag of test is contained in included and excluded tags it will not be executed.\n\n#### `analyze results`\n\nSometimes text file with Robot Framework results should be generated in pretty human readable format.\n\nFor example, we want to copy this result from Kubernetes Pod to Jenkins job and we want text results instead of all\nPod's logs or `html` formatted file. For this purpose `analyze_result.py` module will be executed.\nThis module creates `result.txt` file in `output` folder (with all Robot Framework results) with tests results\nin pretty format. To skip this step environment variable `IS_ANALYZER_RESULT_ENABLED` should be `false`\nit is `true` by default). Default analyzer script is `analyze_result.py` but inheritor image can override it by\n`ANALYZE_RESULT_SCRIPT` environment variable which contains path to custom\nanalyzer script.\n\n#### `write status`\n\nTo integrate with deployer Jenkins Job status of integration tests should be set to watched by Jenkins Job Kubernetes\nentity. It can be as custom resource (CR) as native Kubernetes entities (deployments, pods, etc.).\n\nThe BDI provides an ability to write status of executed tests to some\nKubernetes entity out of the box. Status is written as Kubernetes status condition with the following fields:\n\n* `lastTransitionTime` - timestamp.\n* `message` - parsed results of Robot framework integration tests as string.\n* `reason` - static field with `IntegrationTestsExecutionStatus` value.\n* `status` - can be `True` or `False`. This field depends on `type` field. It is `True` if `type` is `Ready` or `Successful`\n  and `False` if `type` is `Failed` or `In progress`.\n* `type` - can be `Ready`, `Successful`, `Failed` or `In progress`.\n\nFor example:\n\n```yaml\nlastTransitionTime: \"2021-04-21T11:21:31.332Z\"\nmessage: \u003cRobot Framework parsed results\u003e\nreason: IntegrationTestsExecutionStatus\nstatus: \"True\"\ntype: Ready\n```\n\nIn some cases, it is necessary to have `status` field as `boolean` instead of `string`.\n\nFor example:\n\n```yaml\nlastTransitionTime: \"2021-04-21T11:21:31.332Z\"\nmessage: \u003cRobot Framework parsed results\u003e\nreason: IntegrationTestsExecutionStatus\nstatus: true\ntype: Ready\n```\n\nTo support this, environment variable `IS_STATUS_BOOLEAN` must be set to `true`.\nBy default, `IS_STATUS_BOOLEAN` is considered to be `false`.\n\n**Note!** For using feature `write status` in restricted environment, the user or service account used by the\nDeployer should have permissions on entity group with the verbs `get`, `patch` and resources `\u003cresource_plural\u003e/status`\nin current the namespace or project.\n\nFor example, permissions for write status in Custom Resource:\n\n```yaml\n- apiGroups:\n  - qubership.org\n  resources:\n  - platformmonitorings/status\n  verbs:\n  - get\n  - patch\n```\n\nTo write status to some k8s entity you should specify the entity. There are two ways to do this. The first one is to specify\nfull path. For example, you have `ZooKeeperService` custom resource which has\n`metadata.selfLink` field with value - `/apis/qubership.org/v1/namespaces/zookeeper-service/zookeeperservices/zookeeper`,\nin the current approach you should specify `STATUS_CUSTOM_RESOURCE_PATH` environment variable with value from `selfLink`\nwithout `apis` prefix and `namespaces` part:\n\n```ini\nSTATUS_CUSTOM_RESOURCE_PATH=qubership.org/v1/zookeeper-service/zookeeperservices/zookeeper\n```\n\nThe second approach is to point the path in parts using the following environment variables:\n\n```ini\nSTATUS_CUSTOM_RESOURCE_GROUP=qubership.org\nSTATUS_CUSTOM_RESOURCE_VERSION=v1 \nSTATUS_CUSTOM_RESOURCE_NAMESPACE=zookeeper-service\nSTATUS_CUSTOM_RESOURCE_PLURAL=zookeeperservices \nSTATUS_CUSTOM_RESOURCE_NAME=zookeeper\n```\n\nIf your k8s pod with integration tests always writes status to well-known custom resource you can override all this environment\nvariables (excluding `STATUS_CUSTOM_RESOURCE_NAMESPACE`) in your docker file and set namespace in helm chart.\n\nBoth of this approaches work with native k8s entities too. For example:\n\n```ini\nSTATUS_CUSTOM_RESOURCE_GROUP=apps\nSTATUS_CUSTOM_RESOURCE_VERSION=v1\nSTATUS_CUSTOM_RESOURCE_NAMESPACE=zookeeper-service\nSTATUS_CUSTOM_RESOURCE_PLURAL=deployments\nSTATUS_CUSTOM_RESOURCE_NAME=zookeeper-1\n```\n\nIf feature is available `write_status.py` script is called two times. The first time immediately after docker\nentrypoint script was started to set `In progress` condition. The second time after tests are finished and parsed by\n`analyze results` script to set in the `message` field tests results. Default analyzer script is `write_status.py`\nbut inheritor image can override it by `WRITE_STATUS_SCRIPT` environment variable which contains path to custom\n\"write status\" script.\n\nBy default, if all tests are passed BDI set `Ready` value to `type` condition field. There is an ability to deploy only\nintegration tests without any component (component was installed before). In this case you should set\n`ONLY_INTEGRATION_TESTS` environment variable as `true` and BDI will set `Successful` as value of `type`\ncondition field.\n\nThe `message` field in the status condition by default contains first line from `result.txt` file\n(which is generated in the previous step). To write full parsed result you should set `IS_SHORT_STATUS_MESSAGE`\nenvironment variable to `false`.\n\n**Important!** If you use custom script to parse result (`ANALYZE_RESULT_SCRIPT` is not empty) please pay attention\nthat result\nshould be placed in the `result.txt` file and the first line will be used as short status message.\n\n**Note!** This feature (write status to k8s entities) is disabled by default! To turn on it please set the\n`STATUS_WRITING_ENABLED` environment variable to `true`.\nFor example in your docker file as\n\n```ini\nENV STATUS_WRITING_ENABLED=true\n```\n\n## Environment Variables\n\nDocker Integration Tests uses the following environment variables:\n\n* DEBUG\n* TTYD_PORT\n* CUSTOM_ENTRYPOINT_SCRIPT\n* SERVICE_CHECKER_SCRIPT\n* SERVICE_CHECKER_SCRIPT_TIMEOUT\n* IS_TAGS_RESOLVER_ENABLED\n* IS_ANALYZER_RESULT_ENABLED\n* ANALYZE_RESULT_SCRIPT\n* STATUS_CUSTOM_RESOURCE_GROUP\n* STATUS_CUSTOM_RESOURCE_VERSION\n* STATUS_CUSTOM_RESOURCE_NAMESPACE\n* STATUS_CUSTOM_RESOURCE_PLURAL\n* STATUS_CUSTOM_RESOURCE_NAME\n* ONLY_INTEGRATION_TESTS\n* STATUS_CUSTOM_RESOURCE_PATH\n* STATUS_WRITING_ENABLED\n* WRITE_STATUS_SCRIPT\n* IS_SHORT_STATUS_MESSAGE\n* TAGS\n* IS_STATUS_BOOLEAN\n\nAll of them instead of `TAGS`, `ONLY_INTEGRATION_TESTS`, `STATUS_CUSTOM_RESOURCE_NAMESPACE`,\n`STATUS_CUSTOM_RESOURCE_PATH` and maybe `DEBUG` we recommend overriding in the docker file and do not\nforward them to the integration tests deployment environment.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnetcracker%2Fqubership-docker-integration-tests","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnetcracker%2Fqubership-docker-integration-tests","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnetcracker%2Fqubership-docker-integration-tests/lists"}