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

Merge branch 'doc/readme' into 'master'

DOC: switch from master/internal to master/external

See merge request fsl/conda/manifest!15
parents 65e85836 81a22224
......@@ -2,7 +2,7 @@
This repository is used to manage FSL releases. The `fsl-release.yml` file
defines the packages that are installed as part of a FSL release.
defines the packages that are installed as part of a FSL release.
FSL release `manifest.json` and `environment.yml` files are automatically
generated from information stored in this repository, using CI rules and
......@@ -10,8 +10,9 @@ 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
- Public FSL releases are created from tags on the `external` branch.
- Development releases are created from commits on the `external` branch.
- Internal FSL releases are created from the `master` branch
## The `fslinstaller.py` script
......@@ -82,9 +83,9 @@ channels:
- conda-forge
- defaults
# Private internal channel for development and
# testing releases. This is prepended to the
# channels list for development releases.
# Private channel containing packages that are
# only released internally. This is prepended
# to the channels list for internal releases.
internal_channel: http://${FSLCONDA_USERNAME}:${FSLCONDA_PASSWORD}@18.133.213.73/internal/
# List of FSL conda packages and their
......@@ -110,16 +111,17 @@ Note that there are two types of manifest file:
may be re-generated on new public releases, and on updates to e.g. the
fslinstaller script.
- Development manifests, containing information about one
internal/development FSL release. Development manifests are generated for
every internal release. Development manifests are named according to a
standard convention described in the **Internal/development FSL releases**
section, below.
- Development manifests, containing information about one internal or
development FSL release. Development manifests are generated for every
internal or development release. Development manifests are named according
to a standard convention described in the **Internal/development FSL
releases** section, below.
Manifest and environment files can only be published when they are generated
from a new tag, or when they are generated from specific branches (currently
`master` or `internal`).
`master` or `external`). However, manifest and environment files can be
downloaded as GitLab artifacts from any branch.
## New FSL releases
......@@ -133,9 +135,9 @@ _Summary:_
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.
New public FSL releases are denoted by adding a tag to the `external` branch
of 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.
When a new tag is added to this repository, the `manifest.json` and
`environment.yml` files are generated from the contents of `fsl-release.yml`,
......@@ -163,16 +165,16 @@ web interface, via the `deploy-environment-files` and
_Summary:_
- New internal FSL release are created by adding commits to the `internal`
- New internal FSL release may be created by adding commits to the `master`
branch of this repository
- New development releases can be created by adding commits to the `master`
- New development releases may be created by adding commits to the `external`
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
When commits are added to the `master` or `external` 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
......@@ -210,7 +212,7 @@ via the `deploy-environment-files` and `deploy-development-manifest` jobs.
_Summary:_
- The public release `manifest.json` file can be updated by adding commits to
the `master` branch of this repository
the `master` or `external` branches of this repository
- The `deploy-release-manifest` job on the associated CI pipeline must be
started manually.
......@@ -225,11 +227,11 @@ Normally, `manifest.json` files that are not associated with a tag are named
`manifest-<tag>.<date>.<commit>.<branch>.json` as outlined above. However, a
new release `manifest.json` file is always re-generated, and can be deployed
through the Gitlab web interface, via the `deploy-release-manifest` job (with
the caveat that only files generated from the `master` or `internal` branches
the caveat that only files generated from the `master` or `external` branches
may be published).
Release `manifest.json` files which are generated from branches will only
contain information about past official FSL releases. Release `manifest.json`
files which are generated from tags will contain information about past
files which are generated from new tags will contain information about past
official FSL release, and also about the new FSL release.
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