tadam / tcbuildreport Goto Github PK

Kotlin 100.00%

tcbuildreport's Introduction

How to build

Prerequisites:

Java 8
Docker (or exclude buildImage task)

git clone --recurse-submodules https://github.com/tadam/tcbuildreport.git
cd tcbuildreport
./gradlew build

# run backend on http://localhost:8080/
./gradlew backend:run

How to use

Health check

wget -O- -q http://localhost:8080/api/ping

List of running builds

wget --content-on-error -O- -S --header="Content-Type: application/json" --header="Accept: application/json" --post-data='{ "servers": [ { "url": "https://teamcity.jetbrains.com" } ] }' 'http://localhost:8080/api/builds?sortOrder=desc'

Optional query parameters:

sortBy: server | startDate (default server)
sortOrder: asc | desc (default asc)
offset (default 0)
limit (default 10)

Send list of servers as JSON in POST data:

{
  "servers": [
    {
      "url": <teamcity_server_url>,
      "credentials": {
        "login": <login>,
        "password": <password>
      }
    },
    ...
  ]
}

credentials are optional. If not specified, then guest auth will be used.

Response:

{
  "builds": [
    {
      "server": <teamcity_server_url>,
      "id": <build_id>,
      "buildTypeId": <build_type_id>,
      "buildNumber": <build_number>,
      "startDate": <start_date>,
      "webUrl": <teamcity_web_url_for_this_build>
    },
    ...
  ],
  "total": <total_number_of_running_builds_on_all_servers>,
  "errors": [
    "error1",
    "error2",
    ...
  ]

If retrieval of running builds didn't succeed for some reason, it's reflected in errors list.

Deployment in AWS

Read info in deploy.

teamcity-rest-client

Original teamcity-rest-client has been forked to make it asynchronous and add a couple of features. It's added as a git submodule in tcbuildreport.

There is a known issue (XXX) if you try to run this code in Docker container.

tcbuildreport's People

Contributors

Watchers

tcbuildreport's Issues

More RESTful API

Currently the API is some handcrafted JSON protocol.
Ideally server stubs and client implementation should be both generated from the same specification, as well as documentation for it.

Shortly, it'd be nice to make an OpenAPI spec.

Let's see how it goes with
ktorio/ktor#295
and related issues.

Backend hangs in Docker container

There is a strange bug when backend is running in Docker container. Nothing like that happens if the server is running without container.

In some situation buildReceiveJob from here never starts doing anything.

It might be a bug in tcbuildreport project, or somewhere else:
Kotlin/kotlinx.coroutines#276

Will try to make a minimal test case first.

Make some hardcoded backend constants configurable

There are some hardcoded constants in backend, such as fetch timeouts, maximum number of simultaneous connections to a server, etc.

Make it possible to configure it via env variables.

To make the integration with Ktor more smooth, it can be implemented as a custom configuration:
http://ktor.io/servers/configuration.html#custom
Though, didn't find examples on how to do it.

Make integration tests

TeamCity Docker image can be used for integration tests in docker-compose.

TeamCity server assumes that you set a few parameters and accept license agreement during its first run. Approach from ansible-teamcity-server can be used to automate this initial setup.

Would be nice to write frontend logic in Kotlin and compile it to JavaScript.
Some data classes can be common for backend and frontend, just different targets for compilation.
Probably JetBrains/ring-ui can be used here.

Apart from that I know little about frontend. Probably React and Webpack should be used.

Better exception handling in request parameter validation

ktor-locations allow to automatically convert request data into data class.

But for any malformed request this mechanism throws standard exceptions such as IllegalArgumentException. We intercept such exceptions in Ktor's StatusPages, so that we return HTTP 400, rather than 500. But those exceptions could be actually thrown from somewhere else, not only from Ktor validators. So we need to distinguish exception sources somehow.

Would be nice if Ktor itself would wrap exceptions happened in validation into its own exception class.

Fetch optimization

There are some cases when parameters passed in /api/builds (limit, offset, etc.) allow to fetch only a subset of all builds. Let's make this optimization for simple cases.

JAVA_OPTS in container

Currently entry point in Dockerfile specifies java options statically. This way even if container is given more memory, our application won't use it.

Change it to JAVA_OPTS env variable at least.