Create specific binder env for each scikit-decide release

[nhuet]

Summary:
During release.yml workflow, we push a new tag defining the corresponding binder environment, then build and cache it on mybinder.org. Finally the binder links in the release doc point to this specific environment.

Hypotheses:

• a branch named "binder" exists on the repository with an environment.yml file used to define a binder env
• the branch is up-to-date with necessary dependencies to make work the notebooks on master with master version of scikit-decide
• environment.yml file contains the dependency in scikit-decide, and it follows the format scikit-decide[all]==...

Process:

• we checkout binder branch
• we replace the spec for scikit-decide by the scikit-decide version corresponding to the release triggering the workflow
• we commit and push a tag named "binder_vx.x.x" where x.x.x stands for the inferred version number
• we force a build of the environment on mybinder.org to accelerate later call to it
• we use this binder env for links in the doc for the release

Note: we used a quite verbose way to define the BINDER_TAG variable. This is to make it clear that we create it exactly the same way in both jobs "create-binder-env" and "build-docs" , as there is no simple way to share variables between jobs (without using artifacts).

A fake release v0.9.3 has been created on nhuet/scikit-decide to test that the binder environment is well defined.
When the workflow will be finished, we should have a tag "binder_v0.9.3" (see https://github.com/nhuet/scikit-decide/tree/binder_v0.9.3 ) defining the binder environment with scikit-decide 0.9.3 (from pypi), and the environment should have been prebuilt on mybinder.org. Test this link:

[nhuet]

I took into account @dbarbier comments. I force rebased in order to take account the correction that make doc building works (fe50cb9).

[dbarbier]

Looks good. Did you test it on your repo after these changes?

[nhuet]

Yes, i retag a v0.9.3 on my fork. The binder env has been generated (but is now on a binder_test branch as i rebased my binder branch for PR #139) and my online doc is pointing on the proper sha1. See notebooks page here: https://nhuet.github.io/scikit-decide/version/0.9.3/notebooks/

[nhuet]

Actually i just tried to follow the links in doc (thus pointing to the binder env corresponding to the appropriate sha1), and

• it works
• but it rebuild each time => does that mean that pointing to a sha1 prevent binder to understand that it has already been built?
• the second build is still very short because docker has a lot of things in cache => this is because i did it in a row, but i am not sure tomorrow it will be the same. While pointing to a branch or a tag (instead of a sha1) seemed to make binder recognize it as already built and only pull the appropriate docker image from the hub.

[nhuet]

• but it rebuild each time => does that mean that pointing to a sha1 prevent binder to understand that it has already been built?

Nevermind. I tried a 3rd times, and it found the build and only pulled the image. Maybe i was unlucky. It may be due to the fact that mybinder.org is actually deploying binderhub on several cloud infrastructure (cf https://mybinder.readthedocs.io/en/latest/about/federation.html#the-binderhub-federation)