Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AJM: Issue #260: Update documentation to reflect changes in naming conventions for nightly builds and release candidates #261

Merged
merged 1 commit into from
Feb 13, 2024
Merged

AJM: Issue #260: Update documentation to reflect changes in naming conventions for nightly builds and release candidates #261

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions docs/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,9 @@ dbt-setup-release <release> # fddaq-v4.2.1-a9 the latest FD frozen release as of
```
As of July 2023, the DUNE DAQ software stack has been split into far detector and near detector-specific parts. Starting with the `v4.1.0` release of the stack, do _not_ use the traditional convention of `dunedaq-vX.Y.Z` as the frozen release label, but instead, `fddaq-vX.Y.Z` and `nddaq-vX.Y.Z`. Note that for `v4.1.0` and `v4.1.1` we only have a far detector-specific stack.

Instead of a frozen release you can also set up nightly releases or candidate releases using the same arguments as are described later for `dbt-create`; e.g. if you want to set up candidate release `fd-v4.1.0-c5` you can do:
Instead of a frozen release you can also set up nightly releases or candidate releases using the same arguments as are described later for `dbt-create`; e.g. if you want to set up candidate release `fddaq-v4.3.0-rc2-a9` you can do:
```
dbt-setup-release -b candidate fd-v4.1.0-c5
dbt-setup-release -b candidate fddaq-v4.3.0-rc2-a9
```

`dbt-setup-release` will set up both the external packages and DAQ packages, as well as activate the Python virtual environment. Note that the Python virtual environment activated here is read-only.
Expand All @@ -52,19 +52,19 @@ dbt-setup-release -b candidate fd-v4.1.0-c5
If you wish to develop DUNE DAQ software, you can start by creating a work area. Find a directory in which you want your work area to be a subdirectory (home directories are a popular choice) and `cd` into that directory. Then think of a good name for the work area (give it any name, but we'll refer to it as "MyTopDir" in this document).

Each work area is based on a DUNE DAQ software release, which defines what external and DUNE DAQ packages the code you develop in a work area are built against. Releases come in four categories:
* **Nightly Releases**: packages in nightly releases are built each night using the heads of their `develop` branches. Depending on whether it's the far detector stack or the near detector stack, these are generally labeled either as `NFD<YY>-<MM>-<DD>` (far detector) or `NND<YY>-<MM>-<DD>` (near detector). E.g. `NFD23-07-15` is the nightly build for the far detector on July 15, 2023.
* **Nightly Releases**: packages in nightly releases are built each night using the heads of their `develop` and `production/v4` branches. Depending on whether it's the far detector stack or the near detector stack, and whether it's a develop or production build, these are generally labeled either as `NFD_<branch>_<YY><MM><DD>_<OS>` (far detector) or `NND_<branch>_<YY><MM><DD>_<OS>` (near detector). E.g. `NFD_DEV_240213_A9` is the AL9 nightly develop build for the far detector on February 13th, 2024, while `NFD_PROD4_240213_C8` is the CentOS nightly production build for the far detector on the same date. Note that, prior to February 13th, 2024, the labeling convention is `NFD<YY>-<MM>-<DD>` for the far detector stack and `NND<YY>-<MM>-<DD>` for the near detector stack.
* **Frozen Releases**: a frozen release typically comes out every couple of months, and only after extensive testing supervised by a Release Coordinator. Depending on whether it's the far detector stack or the near detector stack, labeled as `fddaq-vX.Y.X` or `nddaq-vX.Y.Z`.
* **Candidate Releases**: a type of release meant specifically for frozen release testing. Generally labeled as `fd-vX.Y.Z-<candidate iteration>` or `nd-vX.Y.Z-<candidate iteration>`, e.g. `fd-v4.1.0-c5`
* **Candidate Releases**: a type of release meant specifically for frozen release testing. Generally labeled as `fddaq-vX.Y.Z-rc<candidate iteration>-<OS>` or `nddaq-vX.Y.Z-rc<candidate iteration>-<OS>`. For example, `fddaq-v4.3.0-rc2-a9` is the second release candidate for the AL9 build of `fddaq-v4.3.0`. Note that, prior to February 13th, 2024, the labeling convention is `fddaq-vX.Y.Z-c<candidate iteration>`

The majority of work areas are set up to build against the most recent nightly release. To do so, run:
```sh
dbt-create -n <nightly release> <name of work area subdirectory> # E.g., NFD23-07-15
dbt-create -n <nightly release> <name of work area subdirectory> # E.g., NFD_DEV_240213_A9
```
To see all available nightly releases, run `dbt-create -l -n` or `dbt-create -l -b nightly`.
You can also use `-n last_fddaq` or `-n last_nddaq` to build against the most recent _production_ branch, e.g., `NFD_PROD4_240213_A9`. To see all available nightly releases, run `dbt-create -l -n` or `dbt-create -l -b nightly`.

If you want to build against a candidate release, run:
```sh
dbt-create -b candidate <candidate release> <name of work area subdirectory> # E.g., fd-v4.1.0-c5
dbt-create -b candidate <candidate release> <name of work area subdirectory> # E.g., fddaq-v4.3.0-rc2-a9
```
...where to see all available candidate releases, run `dbt-create -l -b candidate`.

Expand Down Expand Up @@ -203,7 +203,7 @@ As such, it's important to know the assumptions a work area makes when you use i

A useful script to call to get immediate information on your development environment is `dbt-info`. For a full set of options you can simply run `dbt-info --help`, but for a quick summary, we have the following:

* `dbt-info release`: tells you if it's a far detector or near detector release, what its name is (e.g. `FD23-11-06`), what the name of the base release is, and where the release is located in cvmfs.
* `dbt-info release`: tells you if it's a far detector or near detector release, what its name is (e.g. `NFD_DEV_240213_A9`), what the name of the base release is, and where the release is located in cvmfs.

* `dbt-info package <package name>`: tells you info about the DUNE DAQ package whose name you provide it (git commit hash of its code, etc.). Passing "all" as the package name gives you info for all the DUNE DAQ packages.

Expand All @@ -225,7 +225,7 @@ export DBT_ROOT_WHEN_CREATED="/cvmfs/dunedaq.opensciencegrid.org/tools/dbt/v7.2.
export LOCAL_SPACK_DIR="/home/jcfree/daqbuild_fddaq-v4.1.0/.spack"
```
This file is sourced whenever you run `dbt-workarea-env`, and it tells both the build system and the developer where they can find crucial information about the work areas' builds. Specifically, these environment variables mean the following:
* `$SPACK_RELEASE`: this is the release of the DUNE DAQ software stack against which repos will build (e.g. `fddaq-v4.1.0`, `NFD23-07-15`, etc.)
* `$SPACK_RELEASE`: this is the release of the DUNE DAQ software stack against which repos will build (e.g. `fddaq-v4.3.0-rc2-a9`, `NFD_DEV_240213_A9`, etc.)
* `$SPACK_RELEASES_DIR`: The base of the directory containing the DUNE DAQ software installations.
* `DBT_ROOT_WHEN_CREATED`: The directory containing the `env.sh` file which was sourced before this work area was first created
* `LOCAL_SPACK_DIR`: If the `-s/--spack` was passed to `dbt-create` when the work area was built, this points to where the local Spack area is located
Expand Down