You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/playbook.rst
+53-43Lines changed: 53 additions & 43 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,8 +22,8 @@ Containers
22
22
==========
23
23
24
24
The service consists of two containers.
25
-
The first is a base container with the Science Pipelines "stack" code and networking utilities.
26
-
The second is a service container made from the base that has the Prompt Processing service code.
25
+
The first is a **base container** with the Science Pipelines "stack" code and networking utilities.
26
+
The second is a **service container** made from the base that has the Prompt Processing service code.
27
27
All containers are managed by `GitHub Container Registry <https://github.com/orgs/lsst-dm/packages?repo_name=prompt_processing>`_ and are built using GitHub Actions.
28
28
29
29
To build the base container:
@@ -49,8 +49,8 @@ To build the base container:
49
49
To build the service container:
50
50
51
51
* If there are changes to the service, push them to a branch, then open a PR.
52
-
The container should be built automatically using the ``latest`` base container.
53
-
* To force a rebuild manually, go to the repository's `Actions tab <https://github.com/lsst-dm/prompt_processing/actions/workflows/build-service.yml>`_ and select "Run workflow".
52
+
This will build the container automatically using the ``latest`` base container.
53
+
* To force a rebuild manually, go to the repository's `Actions tab <https://github.com/lsst-dm/prompt_processing/actions/workflows/build-service.yml>`_ and select "**Run workflow**".
54
54
From the dropdown, select the branch whose code should be built.
55
55
The container will be built using the ``latest`` base container, even if there is a branch build of the base.
56
56
* To use a base other than ``latest``, edit ``.github/workflows/_matrix-gen.yaml`` on the branch and override the ``BASE_TAG_LIST`` variable.
@@ -76,7 +76,7 @@ It will sometimes be necessary to compile a container with the LSST Science Pipe
76
76
Generally, this only occurs if the intended daily or weekly stack does not compile.
77
77
In these cases, the Science Pipelines themselves must be built ahead of the base container.
78
78
Instructions for building the Science Pipelines are `here <https://github.com/lsst/gha_build/blob/main/README.md>`_.
79
-
For Prompt Processing, we only need to build `lsst_distrib`.
79
+
For Prompt Processing, we only need to build ``lsst_distrib``.
80
80
81
81
Release Management
82
82
==================
@@ -89,48 +89,63 @@ From the ``main`` branch you can release a new major version (``X.0.0``), a new
89
89
Release tags are semantic version identifiers following the `pep 440 <https://peps.python.org/pep-0440/>`_ specification.
90
90
Please note that the tag does not include a ``v`` at the beginning.
91
91
92
-
1. Choose Version Number
92
+
#. Choosing the Version Number
93
93
94
-
On GitHub.com, navigate to the main page of the repository.
95
-
To the right of the list of files, click the latest release.
96
-
At the top of the page, click **## commits to main since this release**.
97
-
(If there's no such link or it doesn't mention ``main``, the release is probably based off a branch; go up to Releases and try older versions until you find one.)
98
-
This is the list of internal changes that will be included in the next release.
94
+
The first step in making a release is choosing an appropriate version number to describe it. This subsection offers guidance on this choice, as well as on differentiating between major and minor releases.
99
95
100
-
If you are planning to update the Science Pipelines tag, you should also check the `Science Pipelines changelog <https://lsst-dm.github.io/lsst_git_changelog/weekly/>`_.
101
-
In practice, almost any Science Pipelines update is at least a minor version, because new features are added constantly.
102
-
In the future, there may be "patched weekly" builds, which would justify a patch version of Prompt Processing.
96
+
**To see which changes have occurred since the last release:**
103
97
104
-
For the ``prompt_processing`` service, a new major version is triggered by any of the following:
98
+
On GitHub.com, navigate to the main page of the repository.
99
+
To the right of the list of files, click the latest release.
100
+
At the top of the page, click **## commits to main since this release**.
101
+
(If there's no such link or it doesn't mention ``main``, the release is probably based off a branch; go up to Releases and try older versions until you find one.)
102
+
This is the list of internal changes that will be included in the next release.
105
103
106
-
* Incompatibility with old fanned-out ``nextVisit`` messages (almost any change to ``Visit`` qualifies)
107
-
* Incompatibility with an old `APDB schema`_, `ApdbSql`_, `ApdbCassandra`_, or `ApdbCassandraReplica`_ version (see `DMTN-269`_ for the distinction)
108
-
* Incompatibility with an old `Butler dimensions-config`_ version
109
-
* A new major version of the `Alerts schema`_ (see `DMTN-093`_ for details)
104
+
If you are planning to update the Science Pipelines tag, you should also check the `Science Pipelines changelog <https://lsst-dm.github.io/lsst_git_changelog/weekly/>`_.
105
+
In practice, almost any Science Pipelines update is at least a minor version, because new features are added constantly.
106
+
You may need to do a "Quick-Stack" build, or build the science pipelines manually. This would justify a patch version of Prompt Processing.
110
107
111
-
For the `next_visit_fan_out`_ service, a new major version is triggered by any of the following:
108
+
**The following changes will trigger a major release:**
112
109
113
-
* Incompatibility with old Summit ``nextVisit`` messages
114
-
* Breaking changes in the fanned-out ``nextVisit`` messages (almost any change to ``NextVisitModel`` qualifies)
110
+
For the ``prompt_processing`` service:
115
111
116
-
2. Create a Release
112
+
* Incompatibility with old fanned-out ``nextVisit`` messages (almost any change to ``Visit`` qualifies)
113
+
* Incompatibility with an old `APDB schema`_, `ApdbSql`_, `ApdbCassandra`_, or `ApdbCassandraReplica`_ version (see `DMTN-269`_ for the distinction)
114
+
* Incompatibility with an old `Butler dimensions-config`_ version
115
+
* A new major version of the `Alerts schema`_ (see `DMTN-093`_ for details)
117
116
118
-
On GitHub.com, navigate to the main page of the repository.
119
-
To the right of the list of files, click **Releases**.
120
-
At the top of the page, click **Draft a new release**.
121
-
Type a tag using semantic versioning described in the previous section.
122
-
The Target should be the main branch.
117
+
For the `next_visit_fan_out`_ service:
123
118
124
-
Select **Generate Release Notes**.
125
-
This will generate a list of commit summaries and of submitters.
126
-
Add text as follows.
119
+
* Incompatibility with old Summit ``nextVisit`` messages
120
+
* Breaking changes in the fanned-out ``nextVisit`` messages (almost any change to ``NextVisitModel`` qualifies)
127
121
128
-
* Any specific motivation for the release (for example, including a specific feature, preparing for a specific observing run)
129
-
* Science Pipelines version and rubin-env version
130
-
* Supported `APDB schema`_ and `ApdbSql`_/`ApdbCassandra`_/`ApdbCassandraReplica`_ versions (see `DMTN-269`_ for rationale).
131
-
A stack quoting a given minor version is compatible with *older* APDBs of that major version but not necessarily newer ones; for example, a release whose baseline is APDB schema 1.4.0 can access a schema 1.0.0 or 1.4.1 database, but not schema 1.5.
132
-
* Supported `Butler dimensions-config`_ versions
133
-
* The `Alerts schema`_ version used for output (see `DMTN-093`_ for details)
122
+
#. Create a Release
123
+
124
+
On GitHub.com, navigate to the main page of the repository.
125
+
To the right of the list of files, click **Releases**.
126
+
At the top of the page, click **Draft a new release**.
127
+
Type a tag using semantic versioning described in the previous section.
128
+
The Target should be the main branch.
129
+
130
+
.. note::
131
+
132
+
The `auto` option is unreliable if there are no changes in Prompt Processing itself.
133
+
In these cases, if there weren't any eligible Pull Requests since the last tag, it may choose an older version than the latest.
134
+
Select **Generate Release Notes**.
135
+
This will generate a list of commit summaries and of submitters.
136
+
Add text as follows:
137
+
138
+
* Any specific motivation for the release (for example, including a specific feature, preparing for a specific observing run)
139
+
* Science Pipelines version and rubin-env version
140
+
* Supported `APDB schema`_ and `ApdbSql`_/ `ApdbCassandra`_/ `ApdbCassandraReplica`_ versions (see `DMTN-269`_ for rationale).
141
+
A stack quoting a given minor version is compatible with *older* APDBs of that major version but not necessarily newer ones; for example, a release whose baseline is APDB schema 1.4.0 can access a schema 1.0.0 or 1.4.1 database, but not schema 1.5.
142
+
* Supported `Butler dimensions-config`_ versions
143
+
* The `Alerts schema`_ version used for output (see `DMTN-093`_ for details)
144
+
145
+
Select **Publish Release**.
146
+
147
+
The `Release CI <https://github.com/lsst-dm/prompt_processing/actions/workflows/ci-release.yaml>`_ GitHub Actions workflow uploads the new release to GitHub packages.
148
+
This may take a few minutes, and the release is not usable until it succeeds.
The `Release CI <https://github.com/lsst-dm/prompt_processing/actions/workflows/ci-release.yaml>`_ GitHub Actions workflow uploads the new release to GitHub packages.
154
-
This may take a few minutes, and the release is not usable until it succeeds.
0 commit comments