intenthq / gitkv Goto Github PK

In order to be able to deploy the service in a docker environment
we should package it as a docker image

Acceptance Criteria

• Image is built as part of CI
• Image is pushed to docker hub
• Do not generate latest tag

As mentioned inline we don't currently send the correct content type header for requested files e.g. a JSON file should have application/json

• If a returned file is has an applicable MIME type (such as these) it should be used
• If not the header should default to text/plain

This raises the question of how we handle non-textual files being requested (e.g. an image). Gitkv is officially a key value store for text files so should the behaviour be undefined, raise an error or ignore the files entirely?

If reusing a volume that already contains a git repo, when starting it the script will fail and it shouldn't.

We should fetch instead of clone.

We commented the creation of binaries for osx because some of the tests where failing. I'm raising this issues so we don't forget to fix them.

In order to be able to use volumes with git repos in them
It'd be great if we have a docker image that provides git bare repos as volume(s)

Acceptance Criteria

• Can be provided with Git repo/s to clone
• We should be able to provide the list of git repo/s and (one set of) credentials assuming all repos have the same set of credentials
• Ability to configure if it should clone the bare repo or do a regular clone
• Image is published to docker hub

Update Usage section to reflect addition of --repo-root parameter

I was editing Gitkv's integration tests and noticed they timeout if a legitimate URL is used e.g. repo/gitkv?file=README.md

Debugging it with @nathankleyn we've narrowed it down to the communication with the actor holding app state timing out. Currently none of the tests get far enough through the handler function to reach this, which is why we didn't encounter the issue in #28.

As an API client
I want the service to return proper http errors
so that I know if I have to fix my request or it's that the service is down

Acceptance Criteria
This just applies to the code we have for the POC (more may need to be added as the project evolves, to be defined in each new feature/change):

• Repository not found: 404
• File not found: 404
• Reference not found: 404
• No repo/file/reference param: 400
• Other errors: 500

Gitkv panics when starting in the v0.1.2 Docker image with an error:

thread 'main' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like block_on) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', [...].cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.22/src/runtime/enter.rs:38:5

In order to prevent security issues
We should only allow the selection of the git repository based on a predefined list of allowed repos

Acceptance criteria

• The list is populated doing an ls on the repo_root
• If the repo passed as parameter is not the list => 404
• If the repo is in the list, continue doing the operation with that repo
• No string interpolation is done that can lead to leaking internal paths of the server

This was raised by @nathankleyn in #11

In order to have good test coverage
We should add test to the code we built during the POC

Acceptance Criteria

• Critical areas where we are accessing to the git repo given have ~100% line and branch coverage
• Have as many tests as possible in the documentation

Wouldn't it be easier to include the file in the URL path, rather than as a parameter?

We currently use: /repo/business-cat?file=main.go&reference=heads/master
It could instead look like: /repo/business-cat/main.go&reference=heads/master

With the default ref introduced in #24 the most common use case would be very clean: /repo/business-cat/main.go

I'm getting build errors against master:

   Compiling actix-utils v0.4.5
error[E0432]: unresolved import `std::convert::Infallible`
 --> /Users/Kit/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-utils-0.4.5/src/inflight.rs:1:5
  |
1 | use std::convert::Infallible;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^ no `Infallible` in `convert`

error[E0432]: unresolved import `std::convert::Infallible`
 --> /Users/Kit/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-utils-0.4.5/src/keepalive.rs:1:5
  |
1 | use std::convert::Infallible;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^ no `Infallible` in `convert`

error[E0432]: unresolved import `std::convert::Infallible`
 --> /Users/Kit/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-utils-0.4.5/src/order.rs:2:5
  |
2 | use std::convert::Infallible;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^ no `Infallible` in `convert`

error[E0432]: unresolved import `std::convert::Infallible`
 --> /Users/Kit/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-utils-0.4.5/src/time.rs:1:5
  |
1 | use std::convert::Infallible;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^ no `Infallible` in `convert`

error: aborting due to 4 previous errors

As developer,
I want to a have a proper project for the gitkv,
So that we can start collaborating on it and add functionality

Acceptance criteria

• Project has standard Rust structure
• Project has a README file that contains:
  • Description
  • Use cases/Why
  • How to contribute/COC
  • Alternatives

As a millennial I would like gitkv to return directory listings as JSON, rather than a newline delimitated list

Example:

["myFile.txt", "anotherFile.txt", "soManyFiles.txt"]

Current format:

myFile.txt
anotherFile.txt
soManyFiles.txt

As a contributor of the project
I want it to be in some sort of CI
so that I know I haven't broken anything after doing a PR

Acceptance Criteria:

• Uses Travis or Circle CI
• When a PR raised the test is automatically kicked off, PR is blocked from merge if not passed
• The build results are reflected in project badges for quick project status overview