Skip to content
Snippets Groups Projects
Select Git revision
  • 61853908a43e0f3cb842bcaeab5abb69958becf0
  • master default protected
  • swh-lister-update-debian-packages
  • mr/activate-statsd
  • improve-toolbox-msg
  • mr/memray-for-counters
  • wip/wait-for-pypi
  • drop-default-values
  • add-swh-utils-image
  • add-swh-toolbox-application
  • adapt-list-to-list-dependent-apps
  • swh-toolbox-20240905.1
  • swh-lister-20240905.1
  • swh-provenance-20240830.1
  • swh-graph-20240830.1
  • swh-web-20240829.1
  • swh-web-20240828.1
  • swh-counters-20240826.1
  • swh-alter-20240823.1
  • swh-vault-cookers-20240823.1
  • swh-web-20240823.1
  • swh-web-20240822.2
  • swh-toolbox-20240822.1
  • swh-web-20240822.1
  • swh-vault-cookers-20240822.1
  • swh-vault-20240822.1
  • swh-alter-20240820.1
  • swh-vault-cookers-20240820.1
  • swh-web-20240814.1
  • swh-deposit-20240814.1
  • swh-graphql-20240814.1
31 results

swh-apps

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Jenkins for Software Heritage authored
    61853908
    History

    Software Heritage virtual environment packaging manifests

    This repository contains the manifests and scripts to automate the packaging of SWH applications into (fairly) reproducible Python virtual environments, and then onto container images.

    Problem statement

    To move away from our legacy Debian-based packaging and deployment workflow, we are using Python virtual environments to generate (fairly) reproducible deployment environments, that would be consistent between:

    • docker-based local environments
    • "bare VM/Metal" deployments (on Debian systems still managed by puppet)
    • elastic deployments based on k8s
    • CI environments used for testing packages

    We want the input for generating these environments to be declarative (for instance, "I want an environment with swh.provenance"), and the resulting environments to be:

    • frozen (using a consistent, known set of package versions)
    • kept up to date automatically (for our swh packages, as well as the external dependencies)
    • tested before publication (at least to a minimal extent, e.g. ensuring that the tests of the declared input modules are successful before tagging an application as ready to deploy)

    Packaging Workflow

    Each standalone application is generated from an input requirements.txt file. Out of this, a virtualenv is generated and frozen into a requirements-frozen.txt file, which is then used to build container images (when associated with a Dockerfile and an entry point script).

    The frozen requirements file can also be used to deploy virtual environments directly, e.g. on an existing VM or bare metal server.