search

ai-traders / liget

NuGet server and cache running on kestrel in docker
MIT License
222 stars 29 forks source link
cache docker dotnet dotnet-core kestrel nuget nuget-packages nuget-server paket

readme

Build Status

LiGet

Join the chat at https://gitter.im/AI-Traders/liget-server

A NuGet server with linux-first approach.

Why? and goals

There seems to be no good nuget server for hosting private nuget packages and caching, when working mainly with linux and dotnet core. Running windows just to host a several nuget packages seems like a big waste.

This project aims at following:

BaGet fork

TL;DR since 1.0.0 LiGet is a fork of BaGet. Read lower why...

We have previously created and used LiGet from various pojects, just to get it working on dotnet core. When BaGet started to look promissing, we contributed some work there with indention to migrate from LiGet to BaGet and obsolete the project. However, following was deal-breaker:

How is this fork different from upstream BaGet:

Features and limitations

Not implemented:

Usage

See releases to get docker image version.

docker run -ti -p 9011:9011 tomzo/liget:<version>

For persistent data, you should mount volumes:

You should change the default api key (NUGET-SERVER-API-KEY) used for pushing packages, by setting SHA256 into LIGET_API_KEY_HASH environment variable. You can generate it with echo -n 'my-secret' | sha256sum.

On client side

Usage only as private repository

For dotnet CLI and nuget you need to configure nuget config ~/.nuget/NuGet/NuGet.Config with something like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="liget" value="http://liget:9011/api/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

For paket, in paket.dependencies, just specify another source:

source http://liget:9011/api/v3/index.json

Pushing packages

dotnet nuget push mypackage.1.0.0.nupkg --source http://liget:9011/api/v2/package --api-key NUGET-SERVER-API-KEY

Usage as caching proxy

For dotnet CLI and nuget you need to configure nuget config ~/.nuget/NuGet/NuGet.Config with something like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="liget" value="http://liget:9011/api/cache/v3/index.json" protocolVersion="3" />
    <add key="liget" value="http://liget:9011/api/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

For paket, in paket.dependencies, just specify liget as the 2 only sources

source http://liget:9011/api/cache/v3/index.json
# public packages...

source http://liget:9011/api/v3/index.json
# private packages...

Migrating from BaGet

If you have been using BaGet before, then many of your nuget sources in projects, could look like this, e.g. in paket:

source http://my-nuget.com/cache/v3/index.json
# public packages (only in ai-traders fork)

source http://my-nuget.com/v3
# private packages

Above endpoints end up in paket.lock too. LiGet has different endpoints (with /api before endpoints). If you want to deploy LiGet in place of BaGet and (at least temporarily) keep above endpoints, you can enable BaGet compatibity mode in LiGet.

LIGET_BAGET_COMPAT_ENABLED=true

This will enable following behavior:

Importing packages

To make transition from old (<1.0.0) LiGet or any other server which keeps .nupkg files in a directory, there is an import command:

dotnet LiGet.dll import --path dir

In the docker image you can setup environment variable - LIGET_IMPORT_ON_BOOT=/data/simple which will cause liget to first search for nupkg files in $LIGET_IMPORT_ON_BOOT, before starting server. Packages which were already added are skipped. Setting LIGET_IMPORT_ON_BOOT=/data/simple is sufficient for migration from (<1.0.0) LiGet.

Note: you only need to set this variable once to perform initial migration. You should unset it in later deployments to avoid uncessary scanning.

Docker

The simplest start command is

mkdir -p /tmp/liget-test
docker run -p 9011:9011 -v /tmp/liget-test/:/data tomzo/liget

For best reference see the docker directory with Dockerfile and startup script.

Volume

All packages, cache, and temporary data is stored in /data. By default in /data/<backend>.

/data will be always owned by liget. Startup script switches uid/gid at start to fit with whatever was mounted from the host. The exception to this is when /data is owned by root, then liget has to run as root.``

Configuration

Internally .NET Core application is configured by /app/appsettings.json file. But we are generating this file from environment variables to make it more user friendly.

Everything can be configured with environment variables:

Runtime

Every dotnet Core application has .runtimeconfig.json, which can configure garbage collector. You may want to set following:

Kestrel specific:

Cache

Logging

Gelf

LiGet is using GELF provider for Microsoft.Extensions.Logging to optionally configure logging via GELF to graylog. To configure docker image for logging to your graylog, you can set following environment variables:

Development

We rely heavily on docker to create reproducible development environment. This allows to execute entire build process on any machine which has:

You can execute entire build from scratch to e2e tests (like travis).

Then to execute entire build:

./tasks.sh all

This will pull dotnet-dojo docker image which has all build and test dependencies: dotnet SDK, mono, paket CLI, FAKE, Node.js.

Usage of Dojo is optional and you can easily contribute if you have above tools installed on your machine.

Release cycle

Releases are automated from the master branch, executed by GoCD pipeline, release is published only if all tests have passed. Travis executes the same tasks in the same environment and is for reference to the public community. If there is - Unreleased note at the top of Changelog, then release is a preview, tagged as <version>-<short-commit-sha>. Otherwise it is a full release, tagged as <version>.

Submitting patches

  1. Fork and create branch.
  2. Commit your changes.
  3. Submit a PR, travis will run all tests.
  4. Address issues in the review and build failures.
  5. Before merge rebase on master git rebase -i master and possibly squash some of the commits.

Issues

If you have an idea or found a bug, open an issue to discuss it.

License and authors

Firsly, this project is using lots of code from other nuget servers, either as reference or actually porting pieces of code. Credits:

This project is licenced under MIT.