summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <lwirzenius@wikimedia.org>2019-07-26 16:07:04 +0300
committerLars Wirzenius <lwirzenius@wikimedia.org>2019-07-26 16:07:04 +0300
commit54e22557335568e284bf7fe4b11bf59e81e2b717 (patch)
treed34c3e22744a6c755ae12badfe83107134f98aeb
parent8112d81fd7404db9b5b3827b78d0f2bc6edbf5ec (diff)
downloadwmf-ci-arch-54e22557335568e284bf7fe4b11bf59e81e2b717.tar.gz
Add: instuctions for running test suite with Fable.
-rw-r--r--gitlab.md91
1 files changed, 77 insertions, 14 deletions
diff --git a/gitlab.md b/gitlab.md
index 9eb53ae..de4122b 100644
--- a/gitlab.md
+++ b/gitlab.md
@@ -14,6 +14,11 @@ amount of work to prove that the planned architecture is workable.
There are some small differences to the architecture in the planning
document.
+See:
+
+* [CI Future WG](https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG)
+* [CI architecure](https://docs.google.com/document/d/1EQuInEV-eY_5kxOZ8E1qEdLr8fb6ihwOD9V_tpVFWuU/edit)
+
The components are:
* **Gerrit** (or any git server): this is the canonical location for
@@ -143,47 +148,105 @@ use them, and don't have to learn stuff to get started.
The build has the following steps:
-1. Gerrit notifies the controller of a change in a git repo.
+* Gerrit notifies the controller of a change in a git repo.
-2. The controller tells the VCS worker to copy the repo to GitLab, by
+* The controller tells the VCS worker to copy the repo to GitLab, by
doing a "POST /repo" HTTP request.
-3. The VCS worker git clones the repo from Gerrit. It may do a git
+* The VCS worker git clones the repo from Gerrit. It may do a git
pull instead to update an existing clone, but that's an
optimisation, whiche we'll implement when it's needed. The git
operation may require credentials (e.g., security embargoed
repositories), which the VCSWorker has: they're installed when the
host is deployed. No other CI host has those credentials.
-4. The VCS worker pushed the repository to GitLab. This may again
+* The VCS worker pushed the repository to GitLab. This may again
require credentials. The push triggers GitLab CI to run the commit
stage build and test command specified in `.gitlab-ci.yml`.
-5. The VCS worker responds to the POST request from the controller
+* The VCS worker responds to the POST request from the controller
with results.
-6. GitLab tells the Runner host to run the build and test commands.
+* GitLab tells the Runner host to run the build and test commands.
The runner does that.
-7. The Runner uploads any binaries it builds to the artifact store.
+* The Runner uploads any binaries it builds to the artifact store.
-8. The Runner tells GitLab it's finished.
+* The Runner tells GitLab it's finished.
-9. GitLab tells the controller via a webhook that a build has
+* GitLab tells the controller via a webhook that a build has
finished.
-0. The controller tells the deployer to start a deployment, via a
+* The controller tells the deployer to start a deployment, via a
"POST /deploy" HTTP API call.
-0. The deployer fetches the artifacts it has been told to deploy
+* The deployer fetches the artifacts it has been told to deploy
from the artifact store.
-0. The deployer copyies the artifacts to the test environment. (In a
+* The deployer copyies the artifacts to the test environment. (In a
future iteration this will be a more sophisticated deployment
process.)
-0. The deployer responds to the HTTP request from the controller with
+* The deployer responds to the HTTP request from the controller with
the results.
-0. The controller notifies Gerrit of a build and deployment having
+* The controller notifies Gerrit of a build and deployment having
been finished. (Except not in the first iteration.)
+
+# Testing the CI system
+
+We don't test invidual components here, only the CI system as a whole.
+The test consists of building a small C program of the "hello, world"
+variety, and checking that the result works. The repository is at
+<http://git.liw.fi/heippa> and contains a `.gitlab-ci.yml` file, which
+GitLab automatically uses to build the project. The assisting services
+around GitLab then publish the resulting binary to a web server, as
+outlineed above.
+
+[Fable]: https://fable.liw.fi/
+
+To run this test suite, install [Fable][] (see tutorial for
+installation instructions) and then run this command in the source
+tree of this test suite:
+
+```sh
+WMF_TOKEN="(create-token key iss aud 'trigger status')" ftt-codegen --run gitlab.md
+```
+
+First, we trigger the build by telling the controller that a
+repository has changed.
+
+```fable
+given a git repository git://git.liw.fi/heippa with a simple C program
+when I trigger a build with {"git": "git://git.liw.fi/heippa", "ref": "master", "gitlab": "hithere"}
+then HTTP status code is 200
+```
+
+The controller keeps track of running builds, although it can take a
+few seconds for the build status to change. So we wait a bit and then
+check. (This is a simple, but not very good way of implementing this.)
+
+```fable
+when I wait for 5 seconds
+and I check build status
+then response body indicates hithere is building
+```
+
+Then we check that the build succeeds. Again, the build may take a
+while, so we wait a minute.
+
+```fable
+when I wait for 60 seconds
+and I check build status
+then response body indicates hithere is success
+```
+
+Finally, we retrieve the published binary and run it.
+
+```fable
+when I retrieve http://wmf2-testenv.vm.liw.fi/hithere to a local file hithere
+and I run ./hithere
+then the output is "hello, world"
+```
+
+Fin.