Galaxy Release Procedure

The Galaxy release procedure aims to fix all versions of tools used by Galaxy, wrapper versions, interactive tour versions, workflow versions and the Galaxy version itself, towards a major PhenoMeNal release. For Galaxy itself, this is achieved as with any other container, through the container release procedure. For each tool within Galaxy, for a tool that has a release tag pushed by the CI (Jenkins):

1. Obtain the release tag to be used for the tool container, which is available at Jenkins or at the tracking spreadsheet in the column Latest Release Tag built (Automatic). For instance, as of March 2017, the latest release tag for Iso2Flux tool was v0.2_cv1.0.28 and is produced by this building job. Tags starting with dev_ or rc_ are not release tags, and shouldn't be used for this purpose. 1.1. The main developer/maintainer of the container should ideally communicate this desired version/tag to the Galaxy container maintainer. If the developer makes a proper release of the tool, the release tag will be visible both on the spreadsheet and on Jenkins, as explained above. 1.2. The version of the container should be generating successful test runs, available here. 1.3. If the tool participates in a Galaxy workflow, it should have a successful integration test for all workflows it participates here.
2. If not open already, a git flow release process should be opened for this Galaxy container release.
3. Within the release branch of the Galaxy container, make sure that the correct version/tag of the container in process of being added to the release is used in config/phenomenal_tools2container.yaml file of the Galaxy container (you can find the up-to-date version of that file here. Following the Iso2flux example, this would look like:

assignment:
...
- tools_id:
   - iso2flux
  docker_repo_override: container-registry.phenomenal-h2020.eu
  docker_owner_override: phnmnl
  docker_image_override: iso2flux
  docker_tag_override: v0.2_cv1.0.28          
  max_pod_retrials: 3
...

Please note that more than one Galaxy tool id can be assigned to the same container. If this is a new tool for our Galaxy setup, you might as well need to add entries on job_conf.xml and tool_conf.xml, for more details on the setup on these three files, please see Setting up Galaxy wrappers on PhenoMeNal Galaxy Container.

If your tool is still being configured through the deprecated scheme, you might need to edit config/job_conf.xml file of the Galaxy container instead of config/phenomenal_tools2container.yaml, in the appropiate destination entry for the container, in the docker_tag_override entry. Following the Iso2flux example, this looks like:

    <destinations default="local">
        ...other destinations...
        <destination id="iso2flux-container" runner="k8s">
            <param id="docker_repo_override">container-registry.phenomenal-h2020.eu</param>
            <param id="docker_owner_override">phnmnl</param>
            <param id="docker_image_override">iso2flux</param>
            <param id="docker_tag_override">v0.2_cv1.0.28</param>
            <param id="max_pod_retrials">1</param>
            <param id="docker_enabled">true</param>
        </destination>
        ...other destinations...
    </destinations>

4. Update any necessary files in tools/phenomenal/path/to/tool, including the main XML wrapper if it is outdated from the tool repo.
5. Update any needed workflow files or interactive tour files.
6. Start the Galaxy container in development mode using minikube, to check that files added don't break the Galaxy installation, that you can run the tool with data on Galaxy and that you can run any workflow or involved interactive tour. Iterate on the previous points if needed, adjusting the Galaxy tool wrapper or workflow files as needed.
7. Commit changes for the tool to the Galaxy container release branch, and push to the branch. The CI will create from release branches an rc_ tagged container image and a latest, so make sure that the commit doesn't break Galaxy startup (previous point).

As all tool containers are fixed to a release version as specified above, and the Galaxy instance is working correctly, and you have checked that there is no python dependency with untagged sub-dependencies (which would mean that subsequent builds would use different versions of pip packages) make a symbolic pull request from the release branch to master, and ask for reviews of other core developers. When this is accepted, lift the ban to push to master, finalise the git flow release process for the Galaxy container locally, and then push these changes. You have now a PhenoMeNal Galaxy release tagged and build to be part of a major PhenoMeNal release.

Updating a running Galaxy instance

If you want to upgrade a running Galaxy to a newer version you can follow this recipe: The packaging of the services is managed with helm, see also our Developer Recipes. Within a release you will usually keep the same helm chart for Galaxy, but you might want to adjust e.g. the image tag. It is recommended to keep a mygalaxy-config.yaml that contains all variables required by the helm chart together with the deployment. You can then edit/update the image tag in the config file, commit and then execute e.g. helm install -f publicdev-config.yaml --version 1.5.4 galaxy-helm-repo/galaxy-stable. If you have set an environment variable KUBECONFIG=/path/to/admin.conf this allows to run kubectl and also helm remotely. The less you work inside the K8S master itself, the more disposable the cluster is. It is good practice to keep your deployment configuration files in git version control as well.