Skip to content

Latest commit

 

History

History
94 lines (60 loc) · 3.48 KB

release-process.md

File metadata and controls

94 lines (60 loc) · 3.48 KB
Raw

Contents

Release Process, including Docker

Step 1: Update documentation

Update docs repo if your changes affect docs.oceanprotocol.com content.

Step 2. Publish new "Github Release" & Docker image

To create a new release for pdr-backend, follow these steps:

  1. Visit pdr-backend Github Releases. Note the current version number, eg v0.1.4. It follows semantic versioning.
  2. Decide a new version number, by incrementing patch (eg v0.1.5), minor (eg v0.2.0), or major (eg v1.0.0). Major is rare.
  3. Click "Draft a new release".
  4. For tag version, put something like v0.1.5.
  5. For release title, put the same value (like v0.1.5).
  6. For the target, select the main branch, or the most recent commit in main.
  7. Describe the main changes. You can auto-generate a first cut following these instructions, step 8.
  8. Click "Publish release."

What happens then:

  • The pdr-backend Github Releases Page will now include this release
  • CI/CD will automatically build and publish a new Docker image with the release tag, making it available for installation and use.

About PyPi

The release process does not include publishing to pypi.

  • This is because we have explicitly not put pdr-backend into pypi yet. It's not meant to be used as a library yet. In time, it likely will. Just not yet.

About Docker

Docker releases from main

CI/CD will automatically build and publish a new Docker image

To elaborate: we have an automated docker build for pdr-backend main branch and for all releases. Github is already connected to dockerhub.

dockerbuild

Adding Docker branches

If you want to add Docker branches, go to oceanprotocol/pdr-backend.

Then: on "Build rules", add your branch. Below is an example, where Alex is building "pdr-backend: alex" from branch "feature/alex".

dockerbranch

In the last line: you should be able to log in with your username (eg trentmc).

Testing Docker images

We recommend local testing (versus adding more to dockerhub). Here's how.

First, build your image locally with a custom label, eg yaml-cli2.

cd ~/code/pdr-backend
docker build . -t 'oceanprotocol/pdr-backend:yaml-cli2' .

Then, start barge, using the custom label:

cd ~/code/barge
export PDR_BACKEND_VERSION=yaml-cli2
./start_ocean.sh ...<the usual>...

Then, from pdr-backend, use barge as usual.

Pros of local testing:

  • don't pollute dockerhub with one time images
  • no need of cleanups. If a PR is merged, we don't need to delete that branch from dockerhub autobuild.
  • no need of access to dockerhub
  • dockerhub should be used for production ready images only

All Barge READMEs

  • barge.md: the main Barge README
  • barge-calls.md: order of execution from Barge and pdr-backend code
  • release-process.md: pdr-backend Dockerhub images get published with each push to main, and sometimes other branches. In turn these are used by Barge.