开发指南
目录
开发指南¶
本仓库是 Dask 项目的一部分。通用的开发指南，包括在哪里寻求帮助、仓库布局、测试实践以及文档和样式标准，可在主文档中的Dask 开发者指南中找到。
安装¶
按照Dask 开发者指南中描述的方法设置好环境后，您可以使用 git 克隆此仓库
git clone git@github.com:dask/dask-jobqueue.git
并从源码安装
cd dask-jobqueue
python setup.py install
格式化¶
完成更改后，检查您的更改是否通过 flake8 检查并使用 black 格式化
flake8 dask_jobqueue
black dask_jobqueue
要获取 flake8 和 black，只需使用 pip 安装它们。您还可以使用 pre-commit 将它们添加为 pre-commit 钩子。
使用 Docker 化作业调度器进行测试¶
一些测试需要运行一个功能完备的作业队列集群，这通过 Docker 和 Docker compose 工具实现。因此，您必须按照它们的文档在系统上安装它们。
然后您可以使用与 CI 相同的命令在本地运行测试。例如，对于 PBS，您可以运行
source ci/pbs.sh
jobqueue_before_install
jobqueue_install
jobqueue_script
在没有 CI 脚本的情况下测试¶
您还可以手动使用 Docker 化作业调度器启动测试（无需 CI 命令），以便更好地理解正在发生的事情。这基本上是 ci/*.sh 文件中内容的简化版本。
例如对于 Slurm
cd ci/slurm
docker compose pull
# Start a Slurm dockerized cluster
./start-slurm.sh #which is doing docker compose up -d --no-build
# Install dask-jobqueue in Docker container
docker exec slurmctld /bin/bash -c "cd /dask-jobqueue; pip install -e ."
# Run the tests for slurm
docker exec slurmctld /bin/bash -c "pytest /dask-jobqueue/dask_jobqueue --verbose -E slurm -s"
然后您可以关闭 Docker 化集群并从计算机中删除所有容器
docker compose down
在实际作业排队系统上测试¶
如果您已在具有正常工作的作业调度器的高性能计算中心安装了 dask-jobqueue，您也可以在那里启动需要它的测试。这些是函数前面带有 @pytest.mark.env(“scheduler-name”) pytest fixture 的测试。
使用集群“cluster-name”（需要与 pytest.mark.env 中的名称匹配）
pytest dask_jobqueue -E <cluster-name>
所以例如使用 Slurm 集群
pytest dask_jobqueue -E slurm
请注意，此最后的功能尚未经过彻底测试，您可能会遇到超时问题或其他意外故障，具体取决于您的作业调度器配置和负载。
构建 Docker 镜像¶
在底层，CI 命令使用或构建 Docker 镜像。如果您需要更新这些 Docker 镜像，也可以在本地计算机上构建它们。
例如对于 Slurm
cd ci/slurm
cp ../environment.yml environment.yml #The Dockerfile needs the reference Conda environment file in its context to build
docker compose build
如果您之前已完成此操作，您可能想要停止您的 Docker 化集群并刷新构建。
docker compose down
docker compose build --no-cache
更新用于 CI 测试的 Docker 镜像¶
在各种 Docker 化作业调度器 (.github/workflows/ci.yaml) 上测试 dask-jobqueue 的 CI 构建不会在每次运行时都构建 Docker 镜像，而只会从 Dockerhub 拉取它们。它依赖另一个工作流程 (build-docker-images.yaml) 来构建和推送这些镜像。这可以加快 CI 检查。
有时（例如，通常在更新测试的 Python 版本时），我们将需要同时更新 Docker 镜像并相应地修改和运行测试。这应该通过两个不同的 PR 完成
一个用于更新 Docker 镜像。第一个 PR 的测试可能会失败。
另一个用于检查使用新构建的 Docker 镜像的测试，这将在第一个 PR 合并且 build-docker-images 工作流程完成后进行。