A simple artifact repository using nginx and ephemeral tokens.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Peter Šurda 6fcbf233a6 Update 'README.md' 10 months ago
LICENSE Initial commit 10 months ago
README.md Update 'README.md' 10 months ago

README.md

artifact-repository

A simple artifact repository using nginx, WebDAV and ephemeral tokens, for use in buildbot.

design

The repository would have multiple levels of subdirectories, such as:

  • different artifact types, such as dpkg, appimage, exe, ...
  • for different projects and / or builders
  • for build numbers

The files would be publicly downloadable, but uploading or creating new directories would be restricted. The restrictions would use an ephemeral token generated at build start. This will allow write access to specific directories corresponding to that build. Once the build is done, the files can be uploaded using WebDAV, and then the build will make another call for the token to be deleted.

authentication

The token could also use username (e.g. concatenate builder name + build number) and a random password, this way a traditional basic web authentication can be used. There could be a small cherrypy app at a particular URL, which will allow generating a token, but have its own authentication (for the buildbot master). Only by passing this authentication a new token could be obtained. The token could then be written in a simple user/password file and use auth_basic_user_file, looking at the source of nginx, it opens & reads the file for each authentication request, so there is no need to reload when the contents change. The token could also be stored by the cherrypy server and use auth_request.

deployment

Such a system can be easily dockerized and mount a replicated volume (well, probably two volumes, one for the password file with tokens, and one for the artifats inside the repository), with a little bit of preparation the authenticaiton tokens could also be replicated.

buildbot jobs

A buildbot job would then look like this:

  1. get token (maybe the server side would auto-create directories)
  2. run a task, pass the token as an environment variable or something so that it can upload when necessary
  3. revoke token