Publish#

If you want to share your Executors, you can push it to Jina Hub.

There are two types of sharing:

  • Public (default): Anyone can use public Executors without any restrictions.

  • Private: Only people that have the secret can use private Executors.

First publish#

jina hub push [--public/--private] <path_to_executor_folder>

It will return NAME & SECRET, which you will need to use (if the Executor is private) or update the Executor. Please keep them carefully.

Note

If you are logged in to the Hub using our CLI tools (jina auth login or jcloud login), you can push and pull your executors without SECRET.

You can then visit the Hub portal, click on the “Recent” tab and see your published Executor.

Note

If no --public or --private argument is provided, then it is public by default.

Important

Anyone can use public Executors, but to use a private Executor you must know its SECRET.

Update published Executors#

To override or update a published Executor, you must have both NAME and SECRET.

jina hub push [--public/--private] --force-update <NAME> --secret <SECRET> <path_to_executor_folder>

Tagging an Executor#

Tagging can be useful for versioning Executors or differentiating them by their architecture (e.g. gpu, cpu).

jina hub push <path_to_executor_folder> -t TAG1 -t TAG2

You can specify -t or --tags parameter to tag an Executor.

  • If you don’t add the -t parameter, the default tag is latest

  • If you do add the -t parameter and you still want to have the latest tag, you must write it as another -t parameter.

jina hub push .                     # Result in one tag: latest
jina hub push . -t v1.0.0           # Result in one tag: v1.0.0
jina hub push . -t v1.0.0 -t latest # Result in two tags: v1.0.0, latest

If you want to create a new tag for an existing Executor, you can also add the -t option here:

jina hub push [--public/--private] --force-update <NAME> --secret <SECRET> -t TAG <path_to_executor_folder>

Protected tags#

If you don’t want some tags to be later overwritten to keep a stable, consistent behavior, protected tags are the exact thing you are looking for.

You can leverage the --protected-tag option to create protected tags. After being pushed for the first time, the protected tags can not be pushed again.

jina hub push [--public/--private] --force-update <NAME> --secret <SECRET> --protected-tag <PROTECTED_TAG_1> --protected-tag <PROTECTED_TAG_2> <path_to_executor_folder>

Use environment variables#

Sometimes you might want to use private token in requirements.txt to install private dependencies. For security reasons, you don’t want to expose this token to anyone else. The --build-env parameter could help with this situation. For example, now we have requirements.txt like below:

# requirements.txt
git+http://${YOUR_TOKEN}@github.com/your_private_repo

When doing jina hub push, you can pass the --build-env parameter:

jina hub push --build-env YOUR_TOKEN=foo

Note

There are restrictions in terms of naming environment variables:

  • { and } is required when using environment variables in requirements.txt. e.g $YOUR_TOKEN doesn’t work as expected.

  • Environment variables are limited to the uppercase letter and numbers and the _ (underscore), not start with _.

Limitations

There are limitations if you push Executors via --build-env and pull/use it as source code (but doesn’t matter if you use docker image):

  • When you use jina hub pull jinahub://YOUR_EXECUTOR, you must set the corresponding environment variable according to the prompt.

    export YOUR_TOKEN=foo

  • When you use .add(uses='jinahub://YOUR_EXECUTOR') in Flow, you must set the corresponding environment variable also. For example:

    from jina import Flow, Executor, requests, Document
import os

os.environ["YOUR_TOKEN"] = 'foo'
f = Flow().add(uses='jinahub://YOUR_EXECUTOR')

with f:
    f.post(on='/', inputs=Document(), on_done=print)

For multiple environment variables, we can pass it in this way:

jina hub push --build-env FIRST=foo --build-env SECOND=bar