Commit fcab72eb authored by Paul McCarthy's avatar Paul McCarthy 🚵
Browse files

DOC: summaries for public/internal/development releases and manifest updates [skip-ci]

parent c2e6f4dc
......@@ -9,6 +9,11 @@ generated from information stored in this repository, using CI rules and
scripts in the fsl/conda/manifest-rules> repository.
This repository contains two branches:
- Public and development FSL releases are created from the `master` branch
- Internal FSL releases are created from the `internal` branch
## The `fslinstaller.py` script
......@@ -120,6 +125,14 @@ from a new tag, or when they are generated from specific branches (currently
## New FSL releases
_Summary:_
- New public FSL release are created by adding a tag to the `master` branch
of this repository
- The `deploy-release-manifest` and `deploy-environment-files` jobs, on the
CI pipeline for the new tag, must be manually started in order to publish
the new release.
New public FSL releases are denoted by adding a tag to this repository. The
tag is used as the FSL version identifier, which must be of the form
`X.Y.Z[.W]`, where X, Y, Z, and W are integers.
......@@ -138,19 +151,32 @@ conventions:
(e.g. `fsl-6.1.0_linux-64_cuda11.0.yml`).
After they have been generated, the manifest and environment files are
published to the FSL release web server. This publishing step must be manually
triggered through the GitLab web interface, via the `deploy-environment-files`
and `deploy-release-manifest` jobs.
After they have been generated, a test installation of the new release on each
supported platform is performed using the `fslinstaller.py` script, and then
the manifest and environment files are published to the FSL release web
server. This publishing step must be manually triggered through the GitLab
web interface, via the `deploy-environment-files` and
`deploy-release-manifest` jobs.
## Internal/development FSL releases
When commits are added to _any_ branch of this repository, separate
`manifest.json` and `environment.yml` files are generated from the contents of
`fsl-release.yml` and made available for download. These files are assigned a
version identifier of the form `<tag>.<date>.<commit>.<branch>`, where:
_Summary:_
- New internal FSL release are created by adding commits to the `internal`
branch of this repository
- New development releases can be created by adding commits to the `master`
branch of this repository
- In both cases, the `deploy-environment-files` and
`deploy-development-manifest` jobs on the associated CI pipelines must be
started manually.
When commits are added to the `master` or `internal` branch of this
repository, separate `manifest.json` and `environment.yml` files are generated
from the contents of `fsl-release.yml` and made available for download. These
files are assigned a version identifier of the form
`<tag>.<date>.<commit>.<branch>`, where:
where:
......@@ -182,6 +208,13 @@ via the `deploy-environment-files` and `deploy-development-manifest` jobs.
## Updates to `manifest.json`
_Summary:_
- The public release `manifest.json` file can be updated by adding commits to
the `master` branch of this repository
- The `deploy-release-manifest` job on the associated CI pipeline must be
started manually.
Sometimes the contents of the official release `manifest.json` file may need
to be changed independently of a public FSL release - for example, a new
version of the `fslinstaller.py` script may be released, or the `miniconda`
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment