Change Details

The session storage service needs tests (both unit and functional). Coverage should be as close to 100% as feasible. Additionally, we should implement linting (for code style, potential errors, etc) that runs when the (unit) test suite does. All tests should be executed on code commit by our CI system.

The session storage service (aka [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/kask/+/master | kask ]]) has [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/kask/+/master/Makefile | unit, functional, and integration tests ]], and will eventually include a number of other checks (formatting, lint, etc). For the time being, we are proposing to execute integration tests manually against the staging environment prior to release/deployment, but the remainder of these tests/checks need to be issued automatically on patch submission, in the customary fashion. Some considerations: ## Compilation for deployment Kask is written in Go, and so its release artifact is a statically compiled binary executable. Given the security-sensitive nature of this service, we've opted to use build dependencies sourced entirely from what is packaged in Debian Stretch (to piggy-back on the excellent lifecycle/security management provided there). This will make the compilation of release artifacts too error prone to be done on developer workstations; An improperly applied environment variable could result in compilation against the wrong dependencies. The CI environment should be able to compile Kask in a pristine Debian Stretch environment, (with packaged build dependencies applied), and then make the resulting binary available for deployments. ## Functional tests Kask's functional tests require connectivity to a Cassandra database. Additionally, while care has been taken to ensure that tests won't be influenced by previous runs if the environment is re-used, ideally the database would be created fresh on each run, and tore down after.

The session storage service needs tests (both unit and functional(aka [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/kask/+/master | kask ]]) has [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/kask/+/master/Makefile | unit, functional, and integration tests ]], and will eventually include a number of other checks (formatting, lint, etc). Coverage should be as close to 100% as feasiFor the time being, we are proposing to execute integration tests manually against the staging environment prior to release/deployment, but the remainder of these tests/checks need to be issued automatically on patch submission, in the customary fashion. Some considerations: ## Compilation for deployment Kask is written in Go, and so its release artifact is a statically compiled binary executable. AdditionallyGiven the security-sensitive nature of this service, we should implement linting (for code style've opted to use build dependencies sourced entirely from what is packaged in Debian Stretch (to piggy-back on the excellent lifecycle/security management provided there). This will make the compilation of release artifacts too error prone to be done on developer workstations; An improperly applied environment variable could result in compilation against the wrong dependencies. The CI environment should be able to compile Kask in a pristine Debian Stretch environment, potential errors(with packaged build dependencies applied), etc) that runs when the (unit) test suite doesand then make the resulting binary available for deployments. ## Functional tests Kask's functional tests require connectivity to a Cassandra database. All tests should be executed on code commit by our CI systemdditionally, while care has been taken to ensure that tests won't be influenced by previous runs if the environment is re-used, ideally the database would be created fresh on each run, and tore down after.