diff --git a/docs/zh/cloud/cluster_deployment/isulad+k8s/isulad+k8s_environment_deploy.md b/docs/zh/cloud/cluster_deployment/isulad+k8s/isulad+k8s_environment_deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..f79493865b560b3a52170b670d17cae1309badf6 --- /dev/null +++ b/docs/zh/cloud/cluster_deployment/isulad+k8s/isulad+k8s_environment_deploy.md @@ -0,0 +1,386 @@ +# iSulad+k8s环境部署 + +## 准备集群服务器 + +需准备至少3台openEuler机器，建议在openEuler-22.03及以上版本运行。下表为示例搭建机器信息，仅供参考。 + +| 主机名 | IP | 系统版本 | 角色 | 组件 | +|-------|-------------|------------------------|----------|-----------| +| lab1 | 197.xxx.xxx.xxx | openEuler 22.03 LTS SP4 | 控制节点 | iSulad/k8s | +| lab2 | 197.xxx.xxx.xxx | openEuler 22.03 LTS SP4 | 工作节点1 | iSulad/k8s | +| lab3 | 197.xxx.xxx.xxx | openEuler 22.03 LTS SP4 | 工作节点2 | iSulad/k8s | + +## 镜像/软件信息 + +安装过程中需要用到的软件及镜像名称如下表，版本号为示例安装时用到的版本，仅供参考。 + +| 软件 | 版本 | +|------------------------------------|----------| +| iSulad | 2.0.17-2 | +| kubernetes-client | 1.20.2-9 | +| kubernetes-kubeadm | 1.20.2-9 | +| kubernetes-kubelet | 1.20.2-9 | + +| 镜像 | 版本 | +|------------------------------------|----------| +| k8s.gcr.io/kube-proxy | v1.20.2 | +| k8s.gcr.io/kube-apiserver | v1.20.2 | +| k8s.gcr.io/kube-controller-manager | v1.20.2 | +| k8s.gcr.io/kube-scheduler | v1.20.2 | +| k8s.gcr.io/etcd | 3.4.13-0 | +| k8s.gcr.io/coredns | 1.7.0 | +| k8s.gcr.io/pause | 3.2 | +| calico/node | v3.14.2 | +| calico/pod2daemon-flexvol | v3.14.2 | +| calico/cni | v3.14.2 | +| calico/kube-controllers | v3.14.2 | + +如果在无外网环境中搭建，可以从以下链接提前下载对应版本的软件包、相关依赖软件包及镜像： + +1. 软件包下载地址： +2. 镜像下载地址：[https://developer.aliyun.com/mirror/](https://developer.aliyun.com/mirror/) + +## 修改host文件 + +1. 修改主机名，以其中一台机器为例。 + + ```shell + # hostnamectl set-hostname lab1 + # sudo -i + ``` + +2. 配置主机名解析，编辑三台服务器的/etc/hosts文件。 + + ```shell + # vim /etc/hosts + ``` + +3. 在hosts文件中添加以下内容（IP+主机名）。 + + ```text + 197.xxx.xxx.xxx lab1 + 197.xxx.xxx.xxx lab2 + 197.xxx.xxx.xxx lab3 + ``` + +## 环境准备 + +1. 关闭防火墙。 + + ```shell + # systemctl stop firewalld + # systemctl disable firewalld + ``` + +2. 禁用selinux。 + + ```shell + # setenforce 0 + ``` + +3. 关闭系统swap。 + + ```shell + # swapoff -a + # sed -ri 's/.*swap.*/#&/' /etc/fstab + ``` + +4. 网络配置，开启相应的转发机制。 + + ```shell + # cat > /etc/sysctl.d/kubernetes.conf < [!NOTE]说明 + > + > 以下所下载的镜像版本均为示例，具体版本号以上条命令返回结果为准，下同。 + + ```shell + # isula pull k8smx/kube-apiserver:v1.20.15 + # isula pull k8smx/kube-controller-manager:v1.20.15 + # isula pull k8smx/kube-scheduler:v1.20.15 + # isula pull k8smx/kube-proxy:v1.20.15 + # isula pull k8smx/pause:3.2 + # isula pull k8smx/coredns:1.7.0 + # isula pull k8smx/etcd:3.4.13-0 + ``` + +3. 修改已下载的镜像标签。 + + ```shell + # isula tag k8smx/kube-apiserver:v1.20.15 k8s.gcr.io/kube-apiserver:v1.20.15 + # isula tag k8smx/kube-controller-manager:v1.20.15 k8s.gcr.io/kube-controller-manager:v1.20.15 + # isula tag k8smx/kube-scheduler:v1.20.15 k8s.gcr.io/kube-scheduler:v1.20.15 + # isula tag k8smx/kube-proxy:v1.20.15 k8s.gcr.io/kube-proxy:v1.20.15 + # isula tag k8smx/pause:3.2 k8s.gcr.io/pause:3.2 + # isula tag k8smx/coredns:1.7.0 k8s.gcr.io/coredns:1.7.0 + # isula tag k8smx/etcd:3.4.13-0 k8s.gcr.io/etcd:3.4.13-0 + ``` + +4. 删除旧镜像。 + + ```shell + # isula rmi k8smx/kube-apiserver:v1.20.15 + # isula rmi k8smx/kube-controller-manager:v1.20.15 + # isula rmi k8smx/kube-scheduler:v1.20.15 + # isula rmi k8smx/kube-proxy:v1.20.15 + # isula rmi k8smx/pause:3.2 + # isula rmi k8smx/coredns:1.7.0 + # isula rmi k8smx/etcd:3.4.13-0 + ``` + +5. 查看已拉取的镜像。 + + ```shell + # isula images + ``` + +## 安装crictl工具 + +```shell +# yum install -y cri-tools +``` + +## 初始化master节点 + +执行如下命令初始化master节点： + +```shell +# kubeadm init --kubernetes-version v1.20.2 --cri-socket=/var/run/isulad.sock --pod-network-cidr=[指定pod分配IP段] + +//以上参数的解释 +kubernetes-version 为当前安装的版本 +cri-socket 指定引擎为isulad +pod-network-cidr 指定pod分配的ip段 +``` + +根据系统提示输入如下命令： + +```shell +# mkdir -p $HOME/.kube +# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config +# sudo chown $(id -u):$(id -g) $HOME/.kube/config +``` + +初始化成功后，复制最后两行内容，在node节点上执行刚刚复制的命令，将节点加入master集群，如未记录上述命令可通过如下命令生成： + +```shell +# kubeadm token create --print-join-command +``` + +## node节点添加进集群 + +粘贴master上初始化生成的kubeadm join ...命令，并在discovery前添加--cri-socket=/var/run/isulad.sock。 + +## 安装calico网络插件 + +1. 拉取calico镜像。 + + 需要在master节点配置calico网络插件，同时需要在每个节点中提前拉取需要版本的镜像。 + + ```shell + isula pull calico/node:v3.14.2 + isula pull calico/cni:v3.14.2 + isula pull calico/kube-controllers:v3.14.2 + isula pull calico/pod2daemon-flexvol:v3.14.2 + ``` + +2. 在master节点上获取配置文件。 + + ```shell + wget https://docs.projectcalico.org/v3.14/manifests/calico.yaml + ``` + +3. 修改后创建pod。 + + ```shell + # kubectl apply -f calico.yaml + ``` + + - 如需删除使用如下命令： + + ```shell + # kubectl delete -f calico.yaml + ``` + +4. 查看pod信息。 + + ```shell + # kubectl get pod -A -o wide + ``` + +## 查看master节点node信息 + +使用如下命令可查看节点的详细信息： + +```shell +# kubectl get nodes -o wide +``` + +若需要重置node节点，可使用如下命令： + +```shell +# kubeadm reset +``` diff --git "a/docs/zh/cloud/figures/1.\346\237\245\347\234\213\351\234\200\350\246\201\351\225\234\345\203\217.png" "b/docs/zh/cloud/figures/1.\346\237\245\347\234\213\351\234\200\350\246\201\351\225\234\345\203\217.png" new file mode 100644 index 0000000000000000000000000000000000000000..74cdae5726cec83d5d74b0b8bd01694fd388e342 Binary files /dev/null and "b/docs/zh/cloud/figures/1.\346\237\245\347\234\213\351\234\200\350\246\201\351\225\234\345\203\217.png" differ diff --git "a/docs/zh/cloud/figures/10.\350\207\252\345\256\232\344\271\211\351\241\271\347\233\256\345\220\215\347\247\260.jpg" "b/docs/zh/cloud/figures/10.\350\207\252\345\256\232\344\271\211\351\241\271\347\233\256\345\220\215\347\247\260.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..2062c62a6aae63e9700f6ceedf73daea0876eb44 Binary files /dev/null and "b/docs/zh/cloud/figures/10.\350\207\252\345\256\232\344\271\211\351\241\271\347\233\256\345\220\215\347\247\260.jpg" differ diff --git "a/docs/zh/cloud/figures/11.\350\256\276\347\275\256-cicd-runner.png" "b/docs/zh/cloud/figures/11.\350\256\276\347\275\256-cicd-runner.png" new file mode 100644 index 0000000000000000000000000000000000000000..838cf1b6625439e44c7d09162fb71edbe1eaf3d3 Binary files /dev/null and "b/docs/zh/cloud/figures/11.\350\256\276\347\275\256-cicd-runner.png" differ diff --git "a/docs/zh/cloud/figures/12.\350\256\260\344\270\213runner\345\234\260\345\235\200\344\270\216\344\273\244\347\211\214.jpg" "b/docs/zh/cloud/figures/12.\350\256\260\344\270\213runner\345\234\260\345\235\200\344\270\216\344\273\244\347\211\214.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..d3aaaf9ff4b66e4b536bc0afaa33c121bc6b53f6 Binary files /dev/null and "b/docs/zh/cloud/figures/12.\350\256\260\344\270\213runner\345\234\260\345\235\200\344\270\216\344\273\244\347\211\214.jpg" differ diff --git "a/docs/zh/cloud/figures/13.\346\237\245\347\234\213\350\257\201\344\271\246\351\205\215\347\275\256\346\226\207\344\273\266.png" "b/docs/zh/cloud/figures/13.\346\237\245\347\234\213\350\257\201\344\271\246\351\205\215\347\275\256\346\226\207\344\273\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..8e9ce44af5a01670add1b8b2f5a7223a8bd0f35d Binary files /dev/null and "b/docs/zh/cloud/figures/13.\346\237\245\347\234\213\350\257\201\344\271\246\351\205\215\347\275\256\346\226\207\344\273\266.png" differ diff --git "a/docs/zh/cloud/figures/14.\350\257\201\344\271\246\345\257\274\345\205\245\346\226\207\344\273\266.png" "b/docs/zh/cloud/figures/14.\350\257\201\344\271\246\345\257\274\345\205\245\346\226\207\344\273\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..2a1fdb24d6f5c1c9d44cbce08276289adc5c876c Binary files /dev/null and "b/docs/zh/cloud/figures/14.\350\257\201\344\271\246\345\257\274\345\205\245\346\226\207\344\273\266.png" differ diff --git "a/docs/zh/cloud/figures/15.\346\263\250\345\206\214gitlab-runner.jpg" "b/docs/zh/cloud/figures/15.\346\263\250\345\206\214gitlab-runner.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..896f13bdc6411b719283f30d9973973950f27a1c Binary files /dev/null and "b/docs/zh/cloud/figures/15.\346\263\250\345\206\214gitlab-runner.jpg" differ diff --git "a/docs/zh/cloud/figures/16.web\347\253\257\345\267\262\345\212\240\345\205\245_LI.jpg" "b/docs/zh/cloud/figures/16.web\347\253\257\345\267\262\345\212\240\345\205\245_LI.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..fd8ae15ef7bce7120c7ba24b6240b33dbcf610b8 Binary files /dev/null and "b/docs/zh/cloud/figures/16.web\347\253\257\345\267\262\345\212\240\345\205\245_LI.jpg" differ diff --git a/docs/zh/cloud/figures/17.png b/docs/zh/cloud/figures/17.png new file mode 100644 index 0000000000000000000000000000000000000000..86f90a67185f532b362f4710ce8f7615cf40c9e1 Binary files /dev/null and b/docs/zh/cloud/figures/17.png differ diff --git "a/docs/zh/cloud/figures/18.dns\351\205\215\347\275\256.png" "b/docs/zh/cloud/figures/18.dns\351\205\215\347\275\256.png" new file mode 100644 index 0000000000000000000000000000000000000000..46b85396db34577b67679da759b6160ee707dec5 Binary files /dev/null and "b/docs/zh/cloud/figures/18.dns\351\205\215\347\275\256.png" differ diff --git "a/docs/zh/cloud/figures/19.CICD\347\225\214\351\235\242.png" "b/docs/zh/cloud/figures/19.CICD\347\225\214\351\235\242.png" new file mode 100644 index 0000000000000000000000000000000000000000..f8193e005253eb4a6bd036ec8afdf6566f9fd6d2 Binary files /dev/null and "b/docs/zh/cloud/figures/19.CICD\347\225\214\351\235\242.png" differ diff --git "a/docs/zh/cloud/figures/2.calico\351\205\215\347\275\256.png" "b/docs/zh/cloud/figures/2.calico\351\205\215\347\275\256.png" new file mode 100644 index 0000000000000000000000000000000000000000..d656f86d8ce5e110cf240a58e58b05b42aba8c15 Binary files /dev/null and "b/docs/zh/cloud/figures/2.calico\351\205\215\347\275\256.png" differ diff --git "a/docs/zh/cloud/figures/20.yaml\346\226\207\344\273\266.png" "b/docs/zh/cloud/figures/20.yaml\346\226\207\344\273\266.png" new file mode 100644 index 0000000000000000000000000000000000000000..9e7ec858abc2da72c7815a483f3011bf1225ec0f Binary files /dev/null and "b/docs/zh/cloud/figures/20.yaml\346\226\207\344\273\266.png" differ diff --git "a/docs/zh/cloud/figures/21.\346\265\201\346\260\264\347\272\277\347\212\266\346\200\201.png" "b/docs/zh/cloud/figures/21.\346\265\201\346\260\264\347\272\277\347\212\266\346\200\201.png" new file mode 100644 index 0000000000000000000000000000000000000000..fff7063f17fd203390302a6245a8ce4a16cf428e Binary files /dev/null and "b/docs/zh/cloud/figures/21.\346\265\201\346\260\264\347\272\277\347\212\266\346\200\201.png" differ diff --git a/docs/zh/cloud/figures/3.png b/docs/zh/cloud/figures/3.png new file mode 100644 index 0000000000000000000000000000000000000000..7394b5f21821ce8d352c2f935c3ea3e490dc0519 Binary files /dev/null and b/docs/zh/cloud/figures/3.png differ diff --git "a/docs/zh/cloud/figures/4.gitlab\347\275\221\351\241\265\345\205\245\345\217\243.jpg" "b/docs/zh/cloud/figures/4.gitlab\347\275\221\351\241\265\345\205\245\345\217\243.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..d3eb0d59d6dee5051470621a4969651668687789 Binary files /dev/null and "b/docs/zh/cloud/figures/4.gitlab\347\275\221\351\241\265\345\205\245\345\217\243.jpg" differ diff --git "a/docs/zh/cloud/figures/5.\346\237\245\350\257\242\345\257\206\347\240\201.jpg" "b/docs/zh/cloud/figures/5.\346\237\245\350\257\242\345\257\206\347\240\201.jpg" new file mode 100644 index 0000000000000000000000000000000000000000..2e3902815108e9e91a07c382a4aae090b7cc6fe9 Binary files /dev/null and "b/docs/zh/cloud/figures/5.\346\237\245\350\257\242\345\257\206\347\240\201.jpg" differ diff --git "a/docs/zh/cloud/figures/6.\347\231\273\345\275\225\345\220\216\351\241\265\351\235\242.png" "b/docs/zh/cloud/figures/6.\347\231\273\345\275\225\345\220\216\351\241\265\351\235\242.png" new file mode 100644 index 0000000000000000000000000000000000000000..5f4d2c2a9a8bf337263028e859e49499155920b0 Binary files /dev/null and "b/docs/zh/cloud/figures/6.\347\231\273\345\275\225\345\220\216\351\241\265\351\235\242.png" differ diff --git "a/docs/zh/cloud/figures/7.\351\225\234\345\203\217.png" "b/docs/zh/cloud/figures/7.\351\225\234\345\203\217.png" new file mode 100644 index 0000000000000000000000000000000000000000..26c811ae616d2fe86e7b8b75c78ef88aff83616b Binary files /dev/null and "b/docs/zh/cloud/figures/7.\351\225\234\345\203\217.png" differ diff --git "a/docs/zh/cloud/figures/8.\346\226\260\345\273\272\351\241\271\347\233\256.png" "b/docs/zh/cloud/figures/8.\346\226\260\345\273\272\351\241\271\347\233\256.png" new file mode 100644 index 0000000000000000000000000000000000000000..0c56662e6bdedcc78dea32b6e2afada466193096 Binary files /dev/null and "b/docs/zh/cloud/figures/8.\346\226\260\345\273\272\351\241\271\347\233\256.png" differ diff --git "a/docs/zh/cloud/figures/9.\345\210\233\345\273\272\347\251\272\347\231\275\351\241\271\347\233\256.png" "b/docs/zh/cloud/figures/9.\345\210\233\345\273\272\347\251\272\347\231\275\351\241\271\347\233\256.png" new file mode 100644 index 0000000000000000000000000000000000000000..117da11ee289d88b51539e027606cc9da526936a Binary files /dev/null and "b/docs/zh/cloud/figures/9.\345\210\233\345\273\272\347\251\272\347\231\275\351\241\271\347\233\256.png" differ diff --git a/docs/zh/cloud/figures/public_sys-resources/icon-note.gif b/docs/zh/cloud/figures/public_sys-resources/icon-note.gif new file mode 100644 index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda Binary files /dev/null and b/docs/zh/cloud/figures/public_sys-resources/icon-note.gif differ diff --git a/docs/zh/edge_computing/kube_edge/kube_edge_deployment_guide.md b/docs/zh/edge_computing/kube_edge/kube_edge_deployment_guide.md index 9738604a11a2f085db6af7982406a95ef9eec9b1..96a617910ac7180d82de4dff01513352bd42fee4 100644 --- a/docs/zh/edge_computing/kube_edge/kube_edge_deployment_guide.md +++ b/docs/zh/edge_computing/kube_edge/kube_edge_deployment_guide.md @@ -4,7 +4,7 @@ ### KubeEdge -KubeEdge 是一个致力于解决边缘场景问题的开源系统，它将容器化应用程序编排和设备管理的能力扩展到边缘设备。基于 Kubernetes，KubeEdge 为网络、应用程序部署以及云侧与边缘侧之间的元数据同步提供核心基础设施支持。KubeEdge 支持 MQTT，并允许开发人员编写自定义逻辑，在边缘上启用资源受限的设备通信。KubeEdge 由云部分和边缘部分组成，目前均已开源。 +KubeEdge 是一个致力于解决边缘场景问题的开源系统，它将容器化应用程序编排和设备管理的能力扩展到边缘设备。基于 Kubernetes、KubeEdge 为网络、应用程序部署以及云侧与边缘侧之间的元数据同步提供核心基础设施支持。KubeEdge 支持 MQTT，并允许开发人员编写自定义逻辑，在边缘上启用资源受限的设备通信。KubeEdge 由云部分和边缘部分组成，目前均已开源。 > @@ -38,7 +38,7 @@ iSulad 是一个轻量级容器 runtime 守护程序，专为 IOT 和 Cloud 基 ### 下载工具包 -[kubeedge-tools](https://gitee.com/Poorunga/kubeedge-tools) 工具包提供了完备的离线安装包以及部署脚本，降低了部署复杂度并且支持在节点无法访问外网的条件下快速搭建 KubeEdge 集群。 +[kubeedge-tools](https://gitee.com/Poorunga/kubeedge-tools) 工具包提供了完备的离线安装包以及部署脚本，降低了部署复杂度，并且支持在节点无法访问外网的条件下快速搭建 KubeEdge 集群。 ```bash # 下载 kubeedge-tools 工具包并解压（包括云侧和边缘侧） @@ -51,7 +51,7 @@ $ cd kubeedge-tools-master ### 部署 k8s -以下操作仅在云侧执行 +以下操作仅在云侧执行。 #### 初始化云侧环境 @@ -61,7 +61,7 @@ $ ./setup-cloud.sh #### 安装 k8s -k8s 的安装部署使用 openEuler 22.03 SP2 的版本 +k8s 的安装部署使用 openEuler 22.03 SP2 的版本。 #### 安装云侧容器网络 diff --git a/docs/zh/edge_computing/kube_edge/kube_edge_user_document.md b/docs/zh/edge_computing/kube_edge/kube_edge_user_document.md index 6f59f8cf48cc2eeeb4c1695c6b606fa49867dd7f..2b8da61b07828cc02574cb9128c290324db90a3b 100644 --- a/docs/zh/edge_computing/kube_edge/kube_edge_user_document.md +++ b/docs/zh/edge_computing/kube_edge/kube_edge_user_document.md @@ -221,4 +221,4 @@ kubeedge-pi-counter-c69698d6-rb4xz 1/1 Running 0 2m 192 3. 自定义云边消息路由 - + diff --git a/docs/zh/server/_toc.yaml b/docs/zh/server/_toc.yaml index 680cfae4f4235c29188522b614735e83375d05be..f28710346a5635cc1558e3fef178dc877e17c232 100644 --- a/docs/zh/server/_toc.yaml +++ b/docs/zh/server/_toc.yaml @@ -23,6 +23,7 @@ sections: - href: ./maintenance/common_skills/_toc.yaml - href: ./maintenance/common_tools/_toc.yaml - href: ./maintenance/troubleshooting/_toc.yaml + - href: ./maintenance/_toc.yaml - label: 安全 sections: - href: ./security/secharden/_toc.yaml @@ -31,12 +32,14 @@ sections: - href: ./security/cve_ease/_toc.yaml - href: ./security/cert_signature/_toc.yaml - href: ./security/shangmi/_toc.yaml + - href: ./security/secdetector/_toc.yaml - label: 内存与存储 sections: - href: ./memory_storage/lvm/_toc.yaml - href: ./memory_storage/etmem/_toc.yaml - href: ./memory_storage/gmem/_toc.yaml - href: ./memory_storage/hsak/_toc.yaml + - href: ./memory_storage/_toc.yaml - label: 网络 sections: - href: ./network/network_config/_toc.yaml @@ -60,6 +63,8 @@ sections: sections: - href: ./development/application_dev/_toc.yaml - href: ./development/gcc/_toc.yaml + - href: ./development/ai4c/_toc.yaml + - href: ./development/fangtian/_toc.yaml - label: HA高可用 sections: - href: ./high_availability/ha/_toc.yaml diff --git a/docs/zh/server/development/FangTian/_toc.yaml b/docs/zh/server/development/fangtian/_toc.yaml similarity index 100% rename from docs/zh/server/development/FangTian/_toc.yaml rename to docs/zh/server/development/fangtian/_toc.yaml diff --git a/docs/zh/server/development/FangTian/fangtian_environment_configuration.md b/docs/zh/server/development/fangtian/fangtian_environment_configuration.md similarity index 100% rename from docs/zh/server/development/FangTian/fangtian_environment_configuration.md rename to docs/zh/server/development/fangtian/fangtian_environment_configuration.md diff --git a/docs/zh/server/development/FangTian/fangtian_for_linux_waylan_and_openharmony_applications.md b/docs/zh/server/development/fangtian/fangtian_for_linux_waylan_and_openharmony_applications.md similarity index 100% rename from docs/zh/server/development/FangTian/fangtian_for_linux_waylan_and_openharmony_applications.md rename to docs/zh/server/development/fangtian/fangtian_for_linux_waylan_and_openharmony_applications.md diff --git a/docs/zh/server/development/FangTian/figures/arkui_ele.png b/docs/zh/server/development/fangtian/figures/arkui_ele.png similarity index 100% rename from docs/zh/server/development/FangTian/figures/arkui_ele.png rename to docs/zh/server/development/fangtian/figures/arkui_ele.png diff --git a/docs/zh/server/development/FangTian/figures/desktop_simple_apps.png b/docs/zh/server/development/fangtian/figures/desktop_simple_apps.png similarity index 100% rename from docs/zh/server/development/FangTian/figures/desktop_simple_apps.png rename to docs/zh/server/development/fangtian/figures/desktop_simple_apps.png diff --git a/docs/zh/server/development/FangTian/figures/wayland_apps.png b/docs/zh/server/development/fangtian/figures/wayland_apps.png similarity index 100% rename from docs/zh/server/development/FangTian/figures/wayland_apps.png rename to docs/zh/server/development/fangtian/figures/wayland_apps.png diff --git a/docs/zh/server/development/FangTian/overview.md b/docs/zh/server/development/fangtian/overview.md similarity index 100% rename from docs/zh/server/development/FangTian/overview.md rename to docs/zh/server/development/fangtian/overview.md diff --git a/docs/zh/server/installation_upgrade/installation/installation_guide.md b/docs/zh/server/installation_upgrade/installation/installation_guide.md index 5e09ccdca5ef700482924caedae0d3a6d61d2dd1..77bc9ddbdefa1e25971f2a23ffe399c3fb38b518 100644 --- a/docs/zh/server/installation_upgrade/installation/installation_guide.md +++ b/docs/zh/server/installation_upgrade/installation/installation_guide.md @@ -163,7 +163,7 @@ nfs服务器需要用户自己搭建，将iso镜像进行挂载，挂载出的文件拷贝到nfs的共享目录中。其中x86_64为CPU 架构，可根据实际情况使用镜像。 -安装过程中，如果“设置安装源”有疑问，可参考“[选择安装源出现异常](./常见问题及解决方法.html#选择安装源出现异常)”。 +安装过程中，如果“设置安装源”有疑问，可参考“《[选择安装源出现异常](https://docs.openeuler.openatom.cn/zh/docs/common/faq/server/installation_faq1.html#%E9%97%AE%E9%A2%984-%E9%80%89%E6%8B%A9%E5%AE%89%E8%A3%85%E6%BA%90%E5%87%BA%E7%8E%B0%E5%BC%82%E5%B8%B8)》”。 设置完成后，请单击左上角“完成”返回“安装概览”页面。 diff --git a/docs/zh/server/installation_upgrade/installation/installation_modes.md b/docs/zh/server/installation_upgrade/installation/installation_modes.md index 2e2b93c19fcf1cf82de0165b4d499f542dbbf5a7..e9ebf0890701dfacb46caaece79d3339a1eac120 100644 --- a/docs/zh/server/installation_upgrade/installation/installation_modes.md +++ b/docs/zh/server/installation_upgrade/installation/installation_modes.md @@ -37,7 +37,7 @@ 1. 将USB盘连接到该系统中，并执行 dmesg 命令查看相关的日志信息。在该日志的最后可以看到刚刚连接的USB盘所生成的一组信息，应类似如下： - ``` + ```sh [ 170.171135] sd 5:0:0:0: [sdb] Attached SCSI removable disk ``` @@ -46,13 +46,13 @@ 2. 切换为root用户。使用su命令，需要输入相应的密码。 - ``` + ```sh su - root ``` 3. 确保USB盘没有被挂载。使用如下命令进行查询： - ``` + ```sh # findmnt /dev/sdb ``` @@ -60,7 +60,7 @@ - 如果输出以下信息，表明USB盘已经自动挂载。 - ``` + ```sh # findmnt /dev/sdb TARGET SOURCE FSTYPE OPTIONS /mnt/iso /dev/sdb iso9660 ro,relatime @@ -68,13 +68,13 @@ 此时，您需要使用umount命令卸载该设备。 - ``` + ```sh # umount /mnt/iso ``` 4. 使用dd命令将ISO安装镜像直接写入USB盘： - ``` + ```sh # dd if=/path/to/image.iso of=/dev/device bs=blocksize ``` @@ -82,11 +82,11 @@ 例如：如果该ISO镜像文件位于 /home/testuser/Downloads/openEuler-{version}-aarch64-dvd.iso，同时探测到的设备名称为sdb，则该命令如下： - ``` + ```sh # dd if=/home/testuser/Downloads/openEuler-{version}-aarch64-dvd.iso of=/dev/sdb bs=512k ``` >![](./public_sys-resources/icon-note.gif) **说明：** ->如isolinux描述，由mkisofs命令创建的ISO 9660 文件系统会通过BIOS固件启动，但只能从CD、DVD和BD等介质启动。所以在使用dd命令制作x86的启动U盘前需要使用 isohybrid -u your.iso 对iso进行处理，然后正常使用dd命令将iso写入u盘即可。（该问题仅影响X86）。 +>如isolinux描述，由mkisofs命令创建的ISO 9660 文件系统会通过BIOS固件启动，但只能从CD、DVD和BD等介质启动。所以在使用dd命令制作x86的启动U盘前需要使用 isohybrid -u your.iso 对iso进行处理，然后正常使用dd命令将iso写入u盘即可（该问题仅影响X86）。 5. 等待镜像写入完成，拔掉USB盘。 @@ -119,7 +119,7 @@ 对于PXE网络安装，客户机通过支持PXE的网卡，向网络发送请求DHCP信息的广播，请求IP地址等信息。DHCP服务器给客户机提供一个IP地址和其他网络信息如域名服务器、ftp服务器（它提供启动安装程序所必须的文件）的IP地址或主机名，以及服务器上文件的位置。 >![](./public_sys-resources/icon-note.gif) **说明：** ->此处不详细讨论 TFTP、DHCP、HTTP 等服务器配置，相关详细配置请参考“[全自动化安装指导](./使用kickstart自动化安装.html#全自动化安装指导)”。 +>此处不详细讨论 TFTP、DHCP、HTTP 等服务器配置，相关详细配置请参考“《[全自动化安装指导](./using_kickstart_for_automatic_installation.md)》”。 ## 通过qcow2镜像安装 @@ -129,13 +129,13 @@ 1. 安装qemu-img软件包。 - ``` + ```sh # dnf install -y qemu-img ``` 2. 使用qemu-img工具的create命令，创建镜像文件，命令格式为： - ``` + ```sh qemu-img create -f -o ``` @@ -148,7 +148,7 @@ 例如，创建一个磁盘设备大小为32GB、格式为qcow2的镜像文件openEuler-imge.qcow2，命令和回显如下： - ``` + ```sh $ qemu-img create -f qcow2 openEuler-image.qcow2 32G Formatting 'openEuler-image.qcow2', fmt=qcow2 size=34359738368 cluster_size=65536 lazy_refcounts=off refcount_bits=16 ``` @@ -176,4 +176,4 @@ ### 启动安装 -华为公有云的x86虚拟化平台的启动请参见[弹性云服务器 ECS的用户指南](https://support.huaweicloud.com/wtsnew-ecs/index.html)。 +华为公有云的x86虚拟化平台的启动请参见《[弹性云服务器 ECS的用户指南](https://support.huaweicloud.com/wtsnew-ecs/index.html)》。 diff --git a/docs/zh/server/installation_upgrade/installation/installation_modes_1.md b/docs/zh/server/installation_upgrade/installation/installation_modes_1.md index 38331efd8227dff4dc0474f9424968593cf720eb..f549bcbc52d48882567d10c6b5d3cbe10427f798 100644 --- a/docs/zh/server/installation_upgrade/installation/installation_modes_1.md +++ b/docs/zh/server/installation_upgrade/installation/installation_modes_1.md @@ -36,7 +36,7 @@ 2. 右键选择“以管理员身份运行”，打开 Win32 Disk Imager。 3. 在“映像文件”中选择 img 格式的镜像文件路径。 4. 在“设备”中选择待写入的 SD 卡盘符。 -5. 单击“写入”。界面通过任务进度条显示写入 SD 卡的进度。 +5. 单击“写入”，界面通过任务进度条显示写入 SD 卡的进度。 6. 写入完成后会弹出 “写入成功” 的提示框，单击“OK”完成写入。 ## Linux 下刷写镜像 diff --git a/docs/zh/server/installation_upgrade/installation/installation_preparations.md b/docs/zh/server/installation_upgrade/installation/installation_preparations.md index 3b57571d035a409f457a7709e8329c42c68d2d2f..004989c1159c0e0291f9b2e89fb8b5e43612740e 100644 --- a/docs/zh/server/installation_upgrade/installation/installation_preparations.md +++ b/docs/zh/server/installation_upgrade/installation/installation_preparations.md @@ -9,7 +9,7 @@ 请按以下步骤获取openEuler的发布包和校验文件： 1. 登录[openEuler社区](https://openeuler.org)网站。 -2. 点击页面上的“下载”按钮。 +2. 单击页面上的“下载”按钮。 3. 在“获取openEuler”标签下，选择一个版本并进入“社区发行版”页面。点击“所有版本”查看完整版本列表。 4. 在版本列表的“openEuler 24.03 LTS SP1”版本处单击“前往下载”按钮，进入 openEuler 24.03 LTS SP1 版本下载列表。 5. 根据实际待安装环境的架构和场景选择需要下载的 openEuler 的发布包和校验文件。 @@ -34,7 +34,7 @@ ### 简介 -为了确认软件包在传输过程中由于网络原因或者存储设备原因是否出现下载不完整的问题，在获取到软件包后，需要对软件包的完整性进行校验，通过了校验的软件包才能部署。 +为了检查软件包在传输或存储过程中是否因网络或设备问题而不完整，在获取到软件包后，需要对软件包的完整性进行校验，通过了校验的软件包才能部署。 这里通过对比校验文件中记录的校验值和手动方式计算的iso文件校验值，判断软件包是否完整。若两个值相同，说明iso文件完整，否则，iso完整性被破坏，请重新获取iso发布包。 @@ -86,8 +86,8 @@ openEuler所需的最小硬件要求如[表2](#tff48b99c9bf24b84bb602c53229e2541 | :---- | :---- | | 架构 | AArch64或x86_64 | | CPU | 2个CPU | -| 内存 | 不小于4GB（为了获得更好的应用体验，建议不小于8GB） | -| 硬盘 | 不小于32GB（为了获得更好的应用体验，建议不小于120GB） | +| 内存 | 大于等于4GB（为了获得更好的应用体验，建议大于等于8GB） | +| 硬盘 | 大于等于32GB（为了获得更好的应用体验，建议大于等于120GB） | ## 虚拟机的安装要求 diff --git a/docs/zh/server/installation_upgrade/installation/risc_v_qemu.md b/docs/zh/server/installation_upgrade/installation/risc_v_qemu.md index 89a8166a5e2b87bb912a0c1ebbcf6656a20038f2..928d4dbeb3b7b59c87ae2c36f8803bcc4910bfce 100644 --- a/docs/zh/server/installation_upgrade/installation/risc_v_qemu.md +++ b/docs/zh/server/installation_upgrade/installation/risc_v_qemu.md @@ -11,7 +11,7 @@ RISCV_VIRT_CODE.fd RISCV_VIRT_VARS.fd ``` -或者根据[官方文档](https://github.com/tianocore/edk2/tree/master/OvmfPkg/RiscVVirt)本地自行编译最新 EDK2 OVMF 固件。 +或者根据《[官方文档](https://github.com/tianocore/edk2/tree/master/OvmfPkg/RiscVVirt)》本地自行编译最新 EDK2 OVMF 固件。 ### 具备 Penglai TEE 支持的 EFI 固件 diff --git a/docs/zh/server/memory_storage/_toc.yaml b/docs/zh/server/memory_storage/_toc.yaml new file mode 100644 index 0000000000000000000000000000000000000000..bb19a7ef75425beabb62e0f12b3e4cee9673d5ad --- /dev/null +++ b/docs/zh/server/memory_storage/_toc.yaml @@ -0,0 +1,6 @@ +label: 管理内存 +isManual: true +description: 管理内存 +sections: + - label: 管理内存 + href: ./overview.md diff --git a/docs/zh/server/performance/tuning_framework/oeaware/oeaware_user_guide.md b/docs/zh/server/performance/tuning_framework/oeaware/oeaware_user_guide.md index 92b622dcf4fd805ee9033c4c551e11bfbfb705a4..92bedd3403a305668e8d9a47240fd0a621db755a 100644 --- a/docs/zh/server/performance/tuning_framework/oeaware/oeaware_user_guide.md +++ b/docs/zh/server/performance/tuning_framework/oeaware/oeaware_user_guide.md @@ -271,7 +271,7 @@ oeawarectl analysis -t 10 No solution. ``` -报告分为三部分 +报告分为三部分： - Suggest：根据系统运行状态，给出调优建议。 - Network：网络使用情况。 diff --git a/docs/zh/server/releasenotes/releasenotes/contribution.md b/docs/zh/server/releasenotes/releasenotes/contribution.md index dfa92dba434461ede22104f608dd4c3e7cb552ef..24acc55accae0102936a25dc451dbdb40d222b41 100644 --- a/docs/zh/server/releasenotes/releasenotes/contribution.md +++ b/docs/zh/server/releasenotes/releasenotes/contribution.md @@ -6,7 +6,7 @@ openEuler将拥有共同兴趣的人们聚在一起，组成了不同的特别兴趣小组（SIG）。当前已有的SIG请参见[SIG列表](https://www.openeuler.org/zh/sig/sig-list/)。 -我们欢迎并鼓励你加入已有的SIG或创建新的SIG，创建方法请参见[SIG管理指南](https://gitee.com/openeuler/community/blob/master/zh/technical-committee/governance/README.md)。 +我们欢迎并鼓励你加入已有的SIG或创建新的SIG，创建方法请参见《[SIG管理指南](https://gitee.com/openeuler/community/blob/master/zh/technical-committee/governance/README.md)》。 ## 邮件列表和任务 diff --git a/docs/zh/server/releasenotes/releasenotes/key_features.md b/docs/zh/server/releasenotes/releasenotes/key_features.md index bfed4217cc6ffae6ed93d7c7bcf1ca0e84ed76aa..aac1413ac21bb45b13c38335e02ee57472382348 100644 --- a/docs/zh/server/releasenotes/releasenotes/key_features.md +++ b/docs/zh/server/releasenotes/releasenotes/key_features.md @@ -10,7 +10,7 @@ 2. AI框架镜像：以SDK镜像为基础，安装AI框架软件，如PyTorch或TensorFlow。此外，通过此部分镜像也可快速搭建AI分布式场景，如Ray等AI分布式框架。 3. 模型应用镜像：在AI框架镜像的基础上，包含完整的工具链和模型应用。 - 相关使用方式请参考[openEuler AI 容器镜像用户指南](https://forum.openeuler.org/t/topic/4189/4)。 + 相关使用方式请参考《[openEuler AI 容器镜像用户指南](https://forum.openeuler.org/t/topic/4189/4)》。 - **AI for OS**：当前，openEuler和AI深度结合，一方面使用基础大模型，基于大量openEuler操作系统的代码和数据，训练出openEuler Copilot System，初步实现代码辅助生成、智能问题智能分析、系统辅助运维等功能，让openEuler更智能。 - 智能问答：openEuler Copilot System智能问答平台目前支持web和智能shell两个入口。 1. 工作流调度：原子化智能体操作流程：通过采用“流”的组织形式，openEuler Copilot System允许用户将智能体的多个操作过程组合成一个内部有序、相互关联的多步骤“工作流”；即时数据处理：智能体在工作流的每个步骤中生成的数据和结果能够立即得到处理，并无缝传递到下一个步骤；智能交互：在面对模糊或复杂的用户指令时，openEuler Copilot System能主动询问用户，以澄清或获取更多信息。 @@ -18,7 +18,7 @@ 3. RAG：openEluer Copilot System中的RAG技术能更强的适应多种文档格式和内容场景，在不为系统增加较大负担的情况下，增强问答服务体验。 4. 语料治理：语料治理是openEuler Copilot System中的RAG技术的基础能力之一，其通过片段相对关系提取、片段衍生物构建和OCR等方式将语料以合适形态入库，以增强用户查询命中期望文档的概率。 - 相关使用方式请参考[openEuler Copilot System 智能问答用户指南](https://gitee.com/openeuler/docs/tree/stable2-22.03_LTS_SP3/docs/zh/docs/AI/openEuler_Copilot_System/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97) + 相关使用方式请参考《[openEuler Copilot System 智能问答用户指南](https://gitee.com/openeuler/docs/tree/stable2-22.03_LTS_SP3/docs/zh/docs/AI/openEuler_Copilot_System/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97)》。 - 智能调优：openEluer Copilot System 智能调优功能目前支持智能shell入口。 在上述功能入口，用户可通过与openEluer Copilot System进行自然语言交互，完成性能数据采集、系统性能分析、系统性能优化等作业，实现启发式调优。 - 智能诊断： @@ -198,8 +198,8 @@ gala-anteater是一款基于AI的操作系统灰度故障的异常检测平台 gala-anteater通过线上线下相结合，利用在线学习技术，实现模型的线下学习，线上更新，并应用于线上异常检测。 -1. Offline: 首先，利用线下历史KPI数据集，经过数据预处理、特征选择，得到训练集；然后，利用得到的训练集，对无监督神经网络模型（例如Variational Autoencoder）进行训练调优。最后，利用人工标注的测试集，选择最优模型。 -2. Online: 将线下训练好的模型，部署到线上，然后利用线上真实的数据集，对模型进行在线训练以及参数调优，然后利用训练好的模型，进行线上环境的实时异常检测。 +1. Offline：首先，利用线下历史KPI数据集，经过数据预处理、特征选择，得到训练集；然后，利用得到的训练集，对无监督神经网络模型（例如Variational Autoencoder）进行训练调优。最后，利用人工标注的测试集，选择最优模型。 +2. Online：将线下训练好的模型，部署到线上，然后利用线上真实的数据集，对模型进行在线训练以及参数调优，然后利用训练好的模型，进行线上环境的实时异常检测。 ## Aops适配authHub统一用户鉴权 @@ -297,7 +297,7 @@ virtCCA机密虚机特性基于鲲鹏920系列S-EL2能力，在TEE侧实现机 1. 设备直通： 设备直通是基于华为鲲鹏920新型号通过预埋在PCIE Root Complex里的PCIE保护组件，在PCIE总线上增加选通器，对CPU与外设间的通信进行选通，即对SMMU的Outbound Traffic和Inbound Traffic的控制流和数据流进行控制，以此保证整体数据链路的安全性。 -基于virtCCA PCIPC的设备直通能力，实现对PCIE设备的安全隔离和性能提升，存在以下优势: +基于virtCCA PCIPC的设备直通能力，实现对PCIE设备的安全隔离和性能提升，存在以下优势： （1）安全隔离 TEE侧控制设备的访问权限，Host侧软件无法访问TEE侧设备； （2）高性能 diff --git a/docs/zh/server/security/secgear/developer_guide.md b/docs/zh/server/security/secgear/developer_guide.md index c41e8ea0e24d8bfe2bececc8370419ceef13d65e..1945abc7bb9d99fb76c29c375f8aca3961a7d4ba 100644 --- a/docs/zh/server/security/secgear/developer_guide.md +++ b/docs/zh/server/security/secgear/developer_guide.md @@ -53,8 +53,8 @@ cd examples/helloworld 开发步骤如下图所示： 1. 开发非安全侧main函数及接口，管理enclave并调用安全侧函数。 -2. 开发EDL文件（类似C语言头文件定义非安全侧与安全侧交互接口） -3. 开发安全侧接口实现 +2. 开发EDL文件（类似C语言头文件定义非安全侧与安全侧交互接口）。 +3. 开发安全侧接口实现。 4. 调用代码生成工具，根据EDL自动生成非安全侧与安全侧交互源码，并分别编译到非安全侧与安全侧二进制文件中，非安全侧逻辑直接调用安全侧对应的接口即可，无需关心自动的生成的交互代码，降低开发成本。 5. 调用签名工具对安全侧二进制签名，实现安全侧程序可信启动。 diff --git a/docs/zh/server/security/secgear/introduction_to_secgear.md b/docs/zh/server/security/secgear/introduction_to_secgear.md index cb1d697d83b4466d88fc56bbb08a769850589d29..dd788264cf6fd68d988ed93dd155a4077c240138 100644 --- a/docs/zh/server/security/secgear/introduction_to_secgear.md +++ b/docs/zh/server/security/secgear/introduction_to_secgear.md @@ -2,7 +2,7 @@ ## 概述 -随着云计算的快速发展，越来越多的企业把计算业务部署到云上，面对第三方云基础设施，云上用户数据安全面临着巨大的挑战。机密计算是一种基于硬件可信执行环境的隐私保护技术，旨在依赖最底层硬件，构建最小信任依赖，将操作系统、Hypervisor、基础设施、系统管理员、服务提供商等都从信任实体列表中删除，视为未经授权的实体，从而减少潜在的风险，保护可信执行环境中数据的机密性、完整性。然而随着机密计算技术的兴起，业界机密计算技术种类繁多（如主流的Intel SGX、ARM Trustzone、RSIC-V keystone等），各技术SDK也千差万别，给开发者带来较大的开发维护成本，长远考虑，还造成了机密计算应用生态隔离。为方便开发者快速构建保护云上数据安全的机密计算解决方案，openEuler推出机密计算统一开发框架secGear。 +随着云计算的快速发展，越来越多的企业把计算业务部署到云上，面对第三方云基础设施，云上用户数据安全面临着巨大的挑战。机密计算是一种基于硬件可信执行环境的隐私保护技术，旨在依赖最底层硬件，构建最小信任依赖，将操作系统、Hypervisor、基础设施、系统管理员、服务提供商等都从信任实体列表中删除，视为未经授权的实体，从而减少潜在的风险，保护可信执行环境中数据的机密性、完整性。然而随着机密计算技术的兴起，业界机密计算技术种类繁多（如主流的Intel SGX、ARM Trustzone、RISC-V keystone等），各技术SDK也千差万别，给开发者带来较大的开发维护成本，长远考虑，还造成了机密计算应用生态隔离。为方便开发者快速构建保护云上数据安全的机密计算解决方案，openEuler推出机密计算统一开发框架secGear。 ## 架构介绍 diff --git a/docs/zh/tools/devops/eulerpipeline/eulerpipeline_user_guide.md b/docs/zh/tools/devops/eulerpipeline/eulerpipeline_user_guide.md index 6a43fe3445de16a36e6e67fe9365e2ad1df535e5..1a153637f0f044fb4f957671ec5b3091cb207517 100644 --- a/docs/zh/tools/devops/eulerpipeline/eulerpipeline_user_guide.md +++ b/docs/zh/tools/devops/eulerpipeline/eulerpipeline_user_guide.md @@ -82,7 +82,7 @@ EulerPipeline原生开发服务支持基于lkp-tests仓库中的流水线yaml模 - 通过YAML编排需要熟悉流水线支持的语法，流水线支持多版本语法解析，语法版本通过“version”关键字声明，目前仅支持v1.0版本语法。 - - v1.0语法请参考文档：[EulerPipeline原生开发服务流水线语法v1.0](grammar/v1/v1.0_grammar.md) + - v1.0语法请参考文档：[EulerPipeline原生开发服务流水线语法v1.0](v1.0_grammar.md) ![yaml](./image/YAML编排.jpg) diff --git a/docs/zh/tools/devops/eulerpipeline/grammar/v1.1/v1.1_grammar.md b/docs/zh/tools/devops/eulerpipeline/grammar/v1.1/v1.1_grammar.md deleted file mode 100644 index 354fca5b785e887d8233ffebc67baa3d06f248ad..0000000000000000000000000000000000000000 --- a/docs/zh/tools/devops/eulerpipeline/grammar/v1.1/v1.1_grammar.md +++ /dev/null @@ -1,1270 +0,0 @@ -# V1.1语法说明文档 - -workflow，即流水线，是一连串具备一定串并联关系的任务组合，描述一连串的任务之间存在的依赖关系、输入输出参数，以及整个流水线的触发条件。 - -不同版本具备不同的语法规则，从零编写和学会workflow的声明方法请详阅对应版本的文档，避免无法正常解析。 - -## 版本信息 - -| 版本 | v1.1 | -| --- | --- | -| 维护者 | wanglin | -| 创建时间 | 2024-01-03 | -| 是否废弃 | 否 | - -## 1. 语法特性 - -流水线通过YAML描述，描述文件的YAML语法规则基于YAML 1.2版本，书写时需要基于YAML 1.2支持的书写方式进行书写。后文中提及的语法特性是描述的基于此之上的解析规则，不涉及YAML 1.2语法的说明。 - -> YAML（YAML Ain't Markup Language）是一种人类可读的数据序列化标准，它被广泛用于配置文件、数据交换语言、云计算等场景。YAML 1.2 是 YAML 的最新版本，于 2009 年发布。 -> -> 相比于之前的版本，做了一些重要的改进和修正，包括： -> -> - 更严格的类型转换规则，以避免一些常见的类型转换错误。 -> - 支持 JSON，即任何有效的 JSON 文件也是一个有效的 YAML 1.2 文件。 -> - 更好的 Unicode 支持。 -> -> YAML 1.2 的官方文档可以在以下链接找到：[YAML 1.2 官方文档](http://yaml.org/spec/1.2/spec.html)。这份文档详细地描述了 YAML 1.2 的所有特性和语法规则。 - -### 1.0. 编码风格 - -- 键命名风格 - - 为使流水线描述文档风格统一，建议所有的键命名均采用"lower_case"的命名方式，尽量不使用大写字符，如下示例： - - ```yaml - this_is_a_key: value - jobs.this_is_a_job: job - ``` - - 注意：命名风格不等于命名规则，如果不遵循建议的键命名风格并不会出现错误。 - -- 一级key声明风格 - - 一级key的含义为整个YAML文档的第一级键，虽然第一级键无论以何种顺序排列不会影响解析结果，但基于统一风格的出发点考虑，建议用户按照如下顺序对一级key进行排列，且一级key之间通过一行空行间隔，如下示例： - - ```yaml - # 版本声明，可以不存在,则默认使用v1.0语法解析 - version: v1.1 - - # 流水线命名，必填 - name: - - # 流水线触发设置，可以不存在 - on: - - # 流水线变量，可以不存在 - vars: - - # 流水线额外事件声明，可以不存在 - events.xxx: - - # 流水线job声明，至少需要声明一个job - jobs.xxx: - - # 流水线控制流说明 - sequence: - xxx: - ``` - - 对于本版本流水线语法而言，一级key仅识别上述6类关键字，在这七种关键字之外的一级key将被忽略。如果某个关键字不存在，比如vars，剩余关键字建议仍保持上述先后顺序排列。 - - 对于关键字的含义和详细语法说明见后文。 - -- 每行文本长度 - - 为了保持良好的可读性，建议每行文本长度不要超过**80**个字符。这是一种常见的编程规范，可以使代码在大多数编辑器和终端中看起来更清晰。但这并不是强制性的规定，根据实际情况和个人习惯，可以适当调整。 - - 对于长文本，可以利用YAML的特性转行声明，如下示例： - - ```yaml - # 通过"|"语法保留换行符"\n" - key: | - this is a long long story, - you could learn it step by step. - # key = "this is a long long story,\nyou could learn it step by step." - - # 通过"|+"语法保留所有换行符"\n" - key: |+ - this is a long long story, - you could learn it step by step. - - - # key = "this is a long long story,\nyou could learn it step by step.\n\n\n" - - # 通过"|-"语法，去除末尾换行符"\n" - key: |- - this is a long long story, - you could learn it step by step. - - - # key = "this is a long long story,\nyou could learn it step by step." - - # 通过">"语法，虽然内容书写存在换行，但解析后的内容去除换行，以空格代替 - key: > - https://repo1/ - https://repo2/ - # key = "https://repo1/ https://repo2" - ``` - - 更多的说明请参考YAML1.2官方文档（见 **章节1. 语法特性** 开头） - -### 1.1. 基本声明 - -基本声明包含**version**与**name**两个一级key，前者用以锚定语法解析版本，后者用以标识流水线名称。 - -#### 1.1.1. 语法版本声明 - -workflow支持多版本语法解析，对于不声明version的workflow而言，采用默认版本语法（v1.0）进行解析。 -声明版本通过关键字version定义： - -```yaml -# 一般情况下，version会被声明在workflow.yaml的顶部 -# 但version的位置并不会影响解析，确保version并非嵌套于其他key下即可 - -version: v1.1 -``` - -根据声明的version的不同，请查阅不同版本的语法特性介绍。 - -#### 1.1.2. 流水线命名 - -无论在什么版本，workflow的名字均由name字段定义。流水线的名字不要求唯一，可以是任意**字符串**。 - -name为一定需要定义的key，如果流水线yaml中缺少这个key解析器将不予通过。 - -```yaml -version: v1.0 - -name: my workflow -``` - -### 1.2. 触发条件定义 - -#### 1.2.1. workflow支持三种触发方式 - -- 手动触发： 基本的触发方式，不传递触发事件数据的方式，触发后将提交所有不存在依赖的任务 -- 定时触发： 周期性自动触发方式，通过设定时间条件，系统自动触发。 -- webhook触发： git仓库配置服务的webhook回调地址等信息，通过webhook回调请求自动触发。 - - 定时触发和webhook触发方式通过关键字"on"定义，如果不需要这两种触发方式，on可以不声明。 - - 示例： - - ```yaml - version: v1.1 - - name: workflow - - on: - # webhook触发事件定义 - - type: webhook/pr - git_repo: https://gitee.com/openeuler/radiaTest.git - branch: master - # 定时触发事件定义 - - type: cron - crontab: 0 15 10 ? * MON-FRI - - other_keys: other_values - ``` - -#### 1.2.2. webhook触发 - - webhook事件分为webhook/pr，webhook/push，webhook/note，webhook/issue四种类型。 - -- PullRequest类事件 - - 声明的事件键值对必须包含type(webhook/pr)，git_repo(仓库地址)，branch(仓库分支)，action(场景，共8类) - - 即当对应的仓库分支存在PullRequest相关事件时，均会触发此流水线，包括新建PR/删除PR/合入PR/...等事件。 - - 如果需要对PR事件进行更细致的筛选，用户可以指定action进行过滤。 - -- Push类事件 - - 声明的事件键值对必须包含type(webhook/push)，git_repo(仓库地址)，branch(仓库分支) - - 即当对应的仓库分支被推送更新后，均会触发此流水线。 - -- 评论类事件 - - 声明的事件键值对必须包含type(webhook/note)，git_repo(仓库地址)，branch(仓库分支,仅支持PullRequest场景存在)，notable_type(评论主体)，notes(评论钩子) - - 即当对应的仓库分支的指定被评论主体（如PullRequest作为被评论主体）并且评论内容能够匹配评论钩子时，会触发此流水线。 - -- Issue类事件 - - 声明的事件键值对必须包含type(webhook/issue)，git_repo(仓库地址)，state(问题单状态) - - 即当对应的仓库分支存在Issue相关事件时，均会触发此流水线，包括新建issue/删除issue/...等事件。 - - state提供了对issue的场景细分能力，通过配置状态可以拆分不同场景。 - - webhook事件的声明支持矩阵式声明方式，从而帮助减少重复描述，如下所示： - - ```yaml - on: - - type: webhook/note - git_repo: https://gitee.com/openeuler/radiaTest.git - branch: - - master - - dev - - test - notable_type: - - PullRequest - notes: - - /retry - - /retest - ``` - -这个例子意味着多个分支下的PullReques被评论了"/retry"或"/retest"都会触发此流水线 - -以上关于webhook讲解较为粗略，建议阅读更详细的webhook配置文档，以便更好的使用: - - - -特别说明: 如果不仅仅需要触发，还需要在流水线中引用（该特性将在后文详述）触发事件中的字段，建议编辑者通过查阅不同git仓库的webhook文档了解。 - -1. Gitee: - -2. Github: - -3. Gitlab: - -#### 1.2.3. 定时触发事件 - - 当配置的触发事件type字段为[cron，interval，date]值时，说明该事件为定时事件，对于某一个定时任务，type仅可为其中某一个取值，以下为简单示例： - - ```yaml -on: - - type: cron - crontab: 0 15 10 ? * MON-FRI - - type: interval - seconds: 60 - - type: date - run_date: 2024-01-01 00:00:00 - - type: date - run_date: 164900500 - ``` - -以上配置，意味着时间满足任意一个场景时，流水线被执行。 - -关于三种类型的定时参数，参看以下官方文档配置即可: - - - - - - - -### 1.3. 流水线全局变量定义 - -流水线的全局变量通过vars字段声明，当前版本支持字符串、数组、对象（字典/哈希表）三种格式。 - -```yaml -version: v1.1 - -name: workflow - -vars: - # 字符串 - varA: string - # 数组 - varB: - - elementA - - elementB - # 对象（支持多级结构嵌套） - varC: - keyA: valueA - # 嵌套数组 - keyB: - - valueB1 - - valueB2 - # 嵌套对象 - keyC: - keyC1: -``` - -流水线变量定义的目的在于定义整个流水线可以利用的若干变量（常量），定义后的变量可以被流水线任意阶段任务引用，从而避免每个任务对于该变量的重复冗余声明。 - -举例而言，假设某个流水线的10个任务均需要上述案例的varB变量作为Input（输入/入参），则只需要引用varB赋予给对应参数即可。 - -具体的引用方式详见后文对于引用语法的介绍。 - -如果一个流水线不需要定义任何流水线变量时，vars关键字可以不存在: - -```yaml -version: v1.1 - -name: workflow - -other_keys: other_values -``` - -> 💡 注：v1.1相较上一个版本v1.0的新语法说明 - -除了在一级key中声明vars外，还可以在sequence中定义某些job特殊的vars，并且局部vars的优先级高于全局vars。 - -### 1.4. 额外事件声明 - -如果流水线内部的某个任务除了依赖于前置的任务外，还实际依赖于额外的webhook事件，或者依赖于一些额外的事件，则需要对这些额外的事件进行预声明。 - -用户通过events.xxx模式的key进行额外事件的声明，"xxx"为额外事件的命名。 - -**注意：**大多数情况下，用户不需要定义额外事件。额外事件不支持定时以及手动事件声明。 - -#### 1.4.1. webhook事件 - -当定义额外webhook事件时，该事件需求定义的key-values与上文流水线触发设置中介绍的一致，如下示例： - -```yaml -version: v1.1 - -name: workflow - -vars: - -events.eventA: - type: webhook/pr - git_repo: https://gitee.com/openeuler/repository.git - branch: - - master - - dev -``` - -#### 1.4.2. job事件 - -除了webhook事件外，额外事件可以定义一种新的事件类型，即job类型事件。job类型事件分为stage和step两个子类，如下示例： - -```yaml -version: v1.1 - -name: workflow - -vars: - -# 额外事件A - jobA进入boot阶段 -events.eventA: - type: job/stage - job: jobA - job_stage: boot - -# 额外事件B - jobA进入名为testcase001的步骤 -events.eventB: - type: job/step - job: jobA - job_step: testcase001 - -# 额外事件C - jobA进入finish阶段且incomplete -events.eventC: - type: job/stage - job: jobA - job_stage: finish - job_health: incomplete -``` - -job类型的事件除了type和job必填外，其他字段可以根据需求从job类型事件的全集keys中选取（job_stage/job_health/job_step/nickname）。 - -定义后的job类型事件如何使用见后文任务定义和控制流声明章节。 - -### 1.5. 任务定义 - -#### 1.5.1. 基础概念 - -对于所有流水线涉及的任务，都需要通过jobs.xxx模式的一级key进行一次声明，主要目的为定义任务的Input（输入/入参），且每个被声明job的value均要求为对象（字典/哈希表）格式（或者为空）。 - -jobs.xxx类关键字常见的两种二级关键字为**defaults**和**overrides**，这两个二级key可以不声明，但如果具备value，则value必须为对象（字典/哈希表）格式，用以声明待提交的job即为模板所具备的所有参数。 - -如下所示： - -```yaml -name: workflow - -vars: - -# 空value的job缺省声明 -jobs.jobA: - -# 空defaults value, 空overrides value声明 -jobs.jobB: - defaults: - overrides: - -# 缺省defaults，overrides非空声明 -jobs.jobB: - overrides: - # 字符串 - keyA: valueA - # 数组 - keyB: - - valueB1 - - valueB2 - # 对象（支持多级嵌套） - keyC: - keyC1: valueC1 - keyC2: - - valueC2 -``` - -除了嵌套的声明方式，流水线语法支持扁平化的方式减少声明的难度，如下示例： - -```yaml -jobs.jobB: - overrides: - keyC.keyC1: valueC1 - -# 等价于 -jobs.jobB: - overrides: - keyC: - keyC1: valueC1 -``` - -**注意：**这种等价仅于defaults和overrides下有效。 - -defaults和overrides意义如字面含义所示，defaults中定义的key-values如果原job中存在对应key，则以原job中的value为实际提交value；overrides中定义的key-values将无条件覆盖到原job的值提交。 - -对于job的概念，以及原job.yaml的内容，建议查阅compass-ci/lkp-tests的文档进行了解： - -1. 如何向compass-ci/lkp-tests新增job: -2. job的定义: -3. job示例: - -> 💡 注：v1.1相较上一个版本v1.0的新语法说明 - -在v1.1版语法中，允许jobs.XX方式定义job，在sequence控制流中并不全部引用，并不会解析报错。 - -#### 1.5.2. 任务别名定义 - -通常情况下，jobs.xxx模式中xxx即为被声明的job名，如如果计划声明一个ltp-bm的任务，则声明jobs.ltp-bm。但在某些流水线中，可能同一个任务需要运行多次，且任务实际的入参并不相同，因此设计多次声明的可能。在这种情况下，则需要利用"别名"语法特性。 - -别名的声明方式如下示例： - -```yaml -jobs.ltp-bm:first-ltp-bm: - -jobs.ltp-bm:second-ltp-bm: -``` - -这两个被声明的任务实际指向的都是ltp-bm这同一个job，但是因为别名所以流水线会将其看作两个不同的个体。 - -#### 1.5.3. 额外事件依赖声明 - -除了defaults和overrides两种常用的二级keys外，jobs.xxx还支持声明depends字段，本字段用以声明额外依赖（额外事件，即上文**章节1.3**内容的应用） - -```yaml -events.eventA: - xxx: xxx - -events.eventC: - xxx: xxx - -jobs.jobA: - defaults: - default_keyA: valueA - overrides: - override_keyB: valueB - depends: - # 额外依赖于上文中通过events.eventA声明的事件 - # 只需要写key:的形式，不需要填value，填了也会被忽略 - eventA: - # 且额外依赖于上文中通过events.eventC声明的事件 - eventC: -``` - -对于jobA而言，depends字段相当于定义了若干AND逻辑关系的额外依赖，当且仅当所有依赖的事件均发生后jobA才会被提交执行。 - -当depends不声明的时候，jobA的依赖仅取决于其处于控制流的位置（详见后文控制流声明），否则为控制流依赖于额外依赖的逻辑与结果。 - -```yaml -submit_jobA = [jobA's depends parsed from controlflow] AND [jobA's depends defined from 'depends'] -``` - -### 1.6. 控制流声明 - -#### 1.6.1. 基础特性 - -流水线任务的串并行结构通过控制流声明对已通过一级key”jobs.xxx“预声明的各个任务进行编排，通过一级key“sequence”定义，如下所示： - -```yaml -version: v1.1 - -name: workflow - -# jobA:first进入boot阶段 -events.eventA: - type: job/stage - job: jobA - nickname: first - job_stage: boot - -# 定义别名为first的jobA -jobs.jobA:first: - overrides: - -jobs.jobB: - overrides: - # 额外依赖于"jobA:first进入boot阶段"事件 - depends: - eventA: - -# 控制流声明 -sequence: - # 声明并行子结构 - parallel: - # jobA:first和jobB并行 - jobA:first: - jobB: -``` - -控制流声明中，存在sequence、parallel、matrix、vars四种关键字，除了关键字外，所有key都会被认作对已预声明的job的引用。对于所有job的引用，需要确保引用的job全称（包含别名）在流水线一级key中存在（以jobs.xxx预声明）。如果sequence中引用了jobA，但流水线一级key中缺少jobs.jobA这个key，解析器将不会给予通过。 - -**注意：**控制流声明的根（一级key）必须为sequence。 - -- 关键字sequence - - sequence意在声明一个串行结构，在sequence下的所有key将被解析为按声明顺序（从上到下）排列的一连串成员，每一个成员必然依赖于其上面一个的成员。 - - ```yaml - sequence: |---------| |---------| - jobA: = | jobA | =========> | jobB | - jobB: |---------| |---------| - ``` - - sequence和job一样，可以通过sequence:xxx:的方式定义别名，该别名仅在一级串行子结构中存在实际意义，非一级子结构的别名仅起标识作用，具体参考下文stage声明说明。 - - ```yaml - # 根sequence，不可添加别名，为控制流声明关键字 - sequence: - # 一级串行子结构，别名为seqA - sequence:seqA: - # 二级串行子结构，别名为seqB - sequence:seqB: - ``` - - 如上所示，sequence的key并不一定只能是job，当sequence内部的key同样是sequence时，意味着串行结构的嵌套。当然，对于纯sequence的嵌套是不具备实际意义的，仅为分组标识，单纯的串行嵌套相当于没有嵌套。 - - ```yaml - sequence: < - - - - - seqA - - - - - - > - sequence:seqA: |---------| |---------| |---------| - jobA: = | jobA | =========> | jobB | =========> | jobC | - jobB: |---------| |---------| |---------| - jobC: - ``` - -- 关键字parallel - - parallel意在声明一个并行结构，在parallel下的所有key将被解析为并列的若干成员，每一个成员都依赖于整个parallel都前置依赖，互相之间不存在控制流定义的依赖关系（可以存在通过depends额外声明的依赖，额外跳线依赖不被控制流声明控制） - - ```yaml - ___________|___________ - sequence: | | - parallel: |---------| |---------| - jobA: = | jobA | | jobB | - jobB: |---------| |---------| - |______________________| - | - ``` - - 注意，parallel一定不可以声明在workflow.yaml的一级key，对于控制流声明而言，根key一定是sequence。 - - 和sequence一致，parallel也可以以parallel:xxx:的方式定义别名，该别名同样仅在一级并行子结构中存在实际含义，非一级子结构的别名仅起标识作用，具体参考下文stage声明说明。 - - 同理，单纯的并行嵌套相当于没有嵌套，如下示例，等价于jobA、jobB、jobC三者并行。 - - ```yaml - ___ _________________|_______________ - sequence: | | _________|__________ ___ - parallel:prlA: | |---------| |----|----| |----|----| | - jobA: = prlA | jobA | | jobB | | jobC | prlB - parallel:prlB: | |---------| |----|----| |----|----| | - jobB: | | |__________________| _|_ - jobC: _|_ |_______________________________| - | - ``` - -- 关键字matrix - - matrix关键字将在1.7章节中详细说明。 - -> 💡 注：vars关键字为v1.1相较上一个版本v1.0的新语法 - -- 关键字vars - - sequence中声明的vars和一级key中vars的含义和用法完全相同，sequence中的vars存在局部作用域，并且局部作用域的优先级高于全局作用域的优先级，即声明位置越近优先级越高，常用于某些job要引用的变量与全局变量的值不同，需要覆盖全局定义变量的场景。另外，vars可以定义在任意sequence或parallel结构中。 - - 优先级的说明如下示例： - - ```yaml - # 全局定义的变量 - vars: - keyA: valueA - - jobs.job1: - overrides: - key1: ${{ vars.keyA }} - - jobs.job2: - overrides: - key1: ${{ vars.keyA }} - - jobs.job3: - overrides: - key1: ${{ vars.keyA }} - - sequence: - job1: - sequence:s1: - # 此处定义的vars只对sequence:s1结构生效 - vars: - keyA: valueB - job2: - parallel:p1: - # 此处定义的vars只对parallel:p1结构生效 - vars: - keyA: valueC - job3: - - # 各job变量引用的实际值： - # job1.key1 = valueA - # job2.key1 = valueB - # job3.key1 = valueC - - ``` - -#### 1.6.2. job的补充声明 - -由上文可知，job无论是defaults、overrides还是depends的声明，可以声明在jobs.xxx这个key之下，这也是比较推荐的用法。但其实在控制流声明中，用户可以对job进行补充声明，补充的声明将深层update到预定义的job声明中，如下所示： - -```yaml -name: workflow - -jobs.jobA: - defaults: - keyA: valueA - overrides: - keyB: - keyB1: valueB1 - keyB2: - keyB21: valueB21 - -sequence: - jobA: - overrides: - # 与上文中jobs下的overrides特性相同 - # 采用keyB.keyB2.keyB21和keyB.keyB2.keyB22为key，即 - # keyB.keyB2.keyB21: valueB21_new - # keyB.keyB2.keyB22: valueB22 - # 与下述声明方式等价 - keyB: - keyB2: - keyB21: valueB21_new - keyB22: valueB22 -``` - -在这个例子中，sequence中将jobA的预定义的overrides下的keyB21重新定义为valueB2_new，且在keyB2下新创建了一个keyB22的键值对。 - -补充声明特性以对象（字典/哈希表）的递归update实现，一定为控制流中的定义覆写jobs的预定义。 - -> 💡 注：以下为v1.1相较上一个版本v1.0的新语法 - -在sequence中除了可以补充定义job的overrides和defaults字段外，还支持定义always、if、unless执行条件语法。 - -- always关键字 - - always用于决定job是否一定会被提交。在常规控制流的依赖关系中，如果前置job执行失败，后面依赖它的job将会阻塞不会再被提交，如果在job中声明了**always: true**，前置job运行失败或者异常，后面的任务都会被提交。 - - ```yaml - sequence: - jobA: - jobB: - # jobB运行结束，运行结果成功、失败或是异常，jobC都会被提交运行 - jobC: - always: true - - ``` - - always关键字有一种语法糖的写法：jobX！，如下示例的写法和上面yaml作用相同： - - ```yaml - sequence: - jobA: - jobB: - # jobB运行结束，运行结果成功、失败或是异常，jobC都会被提交运行 - jobC!: - - ``` - -​ 另外，如果always关键字没有声明，缺省值取false。 - -- if/unless关键字 - - if和unless关键字用于控制job是否需要被提交，如果if条件判断的结果为true，job才会被提交，否则此job将被跳过，并将job_stage设置为finish，job_health设置为skipped，unless的判断逻辑和if正好相反。 - - ```yaml - sequence: - jobA: - jobB: - if: ${{ jobs.jobA.result.id }} # 如果jobA的result.id有值，jobB会被提交，否则jobB不会被运行 - jobC: - ``` - - 如果job中没有声明关键字if，缺省值取true；如果job中always和if关键字同时存在，优先判断if关键字的执行逻辑。 - -### 1.7. 流水线阶段(stage)声明 - -在**章节1.6. 控制流声明**中有提及，无论是sequence还是parallel分别可以通过sequence:xxx:和parallel:xxx:的形式声明别名。流水线web服务将基于下述规则划分控制流的不同阶段，规则如下所示： - -1. 当且仅当sequence和parallel为根sequence下的一级结构时，其别名等同于阶段名。 -2. 当根sequence下存在job名时（非sequence也非parallel），该job以自身job的别名作为阶段名（若无别名则以job名）独立被识别为一个阶段。 -3. 阶段存在向后包裹的特点，直到下一个有效阶段声明前，所有结构属于同一个阶段。 -4. 沿着根sequence向下检索，在遇到第一个有效的stage命名之前，所有的结构均属于“未命名”阶段。 - -```yaml -sequence: - 阶段(stage) - parallel: ——｜ - job0: > 未命名 - job1: ——｜ - - job2:build-job: —— > build-job - - jobA: ——｜ - sequence: > jobA - jobB: ——｜ - - parallel:prlA: ——｜ - jobC: ｜ - jobD: ｜ - sequence:seqB: > prlA - jobE: ｜ - jobF: ——｜ - - sequence:seqC: —— > seqC - jobG: ——｜ -``` - -p.s. 阶段仅会影响web端的渲染，控制流的实际意义不依赖于阶段的定义，换而言之，如果不考虑可视化的便利性，可以不对阶段命名深究。 - -### 1.8. Matrix语法特性 - -#### 1.8.1. 基本概念 - -用户可以在控制流**串行结构的任意位置**可以插入一个matrix关键字，用以混入(Mixin)局部的矩阵(参数组合)，从而改变后续任务的上下文(Context)。 - -matrix关键字同样可以声明别名，用以避免对象（字典/哈希表）的重key异常，但除了区别外没有实际意义。 - -**注意：** matrix不能直接声明在parallel关键字下，只能声明在sequence关键字下。 - -matrix的声明结构一定为如下格式: - -```yaml -sequence: - matrix: - paramA: - - valueA1 - - valueA2 - - valueAn - paramB: - - valueB1 - - valueB2 -``` - -即，matrix是一个对象（字典/哈希表），且所有一级value均为数组（列表）。 - -上述例子中matrix的含义为，对所处位置的流水线上下文混入矩阵，其中paramA有三种可能的取值，paramB有两种可能的取值，即共3*2共6种取值组合。 - -```yaml -matrix: _ - paramA: | 1. paramA = valueA1; paramB = valueB1 - - valueA1 | 2. paramA = valueA1; paramB = valueB2 - - valueA2 | 3. paramA = valueA2; paramB = valueB1 - - valueAn => { 4. paramA = valueA2; paramB = valueB2 - paramB: | 5. paramA = valueAn; paramB = valueB1 - - valueB1 |_ 6. paramA = valueAn; paramB = valueB2 - - valueB2 -``` - -当流水线上下文混入(Mixin)一个局部的矩阵后，流水线的上下文将会根据参数取值组合的种数裂解成多个“分支”，每一个“分支”的上下文依据其中一种取值组合。当这个分支之后的任务直接引用上下文中的paramA时，会根据当前上下文的paramA取值，后续任务的驱动也会与其他”分支“独立。 - -举例而言： - -```yaml -sequence: - jobA: - parallel: - jobB: - sequence: - matrix: - arch: - - aarch64 - - x86_64 - jobC: - jobD: -``` - -根据 **章节1.5. 控制流声明** 的介绍，不难看出，这个描述声明的结构如下： - -```yaml - ________ - | | - |-------| jobB |----------------------------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | - | / \ | | | - |-------| matrix |-------| jobC |---------| - \ / |________| - 1. arch = aarch64; - 2. arch = x86_64 -``` - -对于jobA和jobB，如果他们在被提交的时候引用“当前上下文”（所谓当前为被提交的时间点）中的arch变量，他们将取不到任何值。 - -p.s. 关于引用的概念详见**章节1.6.** - -而对于jobC和jobD而言，他们实际上被裂解到了并行的两个“分支”上，其中一个分支上下文中的arch是aarch64而另一个分支上的arch是x86_64，即上述控制流结构等价于： - -```yaml -1. arch = aarch64; - ________ - | | - |----------| jobB |---------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | aarch64 - | | | | - |----------| jobC |---------| - |________| - aarch64 - -2. arch = x86_64 - ________ - | | - |----------| jobB |---------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | x86_64 - | | | | - |----------| jobC |---------| - |________| - x86_64 -``` - -这两个矩阵参数组合“分支”共享jobA和jobB的前置依赖，但aarch64的jobD只会依赖于aarch64的jobC，即各分支依赖独立。 - -这样避免了在很多场景下的相同结构的重复声明。 - -#### 1.8.2. 矩阵x矩阵 - -流水线控制流支持多matrix在不同位置声明，在这种情况下，下文矩阵受到上文矩阵影响，下文矩阵实际为上下文矩阵相乘的结果，如下示例: - -```yaml -sequence: - matrix:m1: - os: - - openeuler - os_version: - - 20.03 - - 22.03-LTS - jobA: - matrix:m2: - arch: - - aarch64 - - x86_64 - jobB: -``` - -对于这个例子而言，jobA共有两种上下文分支，而jobB共有4种，如下所示： - -```yaml - ________ ________ - | | | | ---------------| jobA |-----------------------------------------| jobB |-----------------------> - |________| |________| - 1. os=openeuler; os_version=20.03 1. os=openeuler;os_version=20.03;arch=aarch64; - 2. os=openeuler; os_version=22.03-LTS 2. os=openeuler;os_version=20.03;arch=x86_64; - 3. os=openeuler;os_version=22.03-LTS;arch=aarch64; - 4. os=openeuler;os_version=22.03-LTS;x86_64; -``` - -因此对于声明此例控制流的关于jobA和jobB的流水线，实际jobA将会被提交两次，jobB将会被提交4次，jobB的1和2分支依赖于jobA的1分支，jobB的3和4分支依赖于jobA的2分支，jobB的最终参数组合即jobA之前声明的matrix与jobB之前的matrix相乘的结果。 - -#### 1.8.3. excludes语法特性 - -matrix支持通过excludes声明排除特定的组合，如下所示： - -```yaml -sequence: - matrix: - os: - - openeuler - - centos - os_version: - - "20.03" - - 7 - excludes: - # 下述两种描述形式均可支持 - - {"os": "openeuler", "os_version": "7"} - - os: centos - os_version: "20.03" -``` - -此声明方式意为此矩阵只存在两种参数组合，即 ”os=openeuler;os_version=20.03“ 和 “os=centos;os_version=7”。 - -#### 1.8.4. 参数组合语法糖 - -同时，matrix具备一种简化excludes声明的语法糖"|"，以上述样例可以改写为： - -```yaml -sequence: - matrix: - os|os_version: - - openeuler | 20.03 #有无空格或者制表符均支持 - - centos | 7 #推荐以制表符分隔，这样的声明较为直观 -``` - -### 1.8. "引用"表达式声明 - -#### 1.8.1. 基本概念 - -对于一条正在运作的流水线而言，其上下文是动态的，每执行完成一个任务，每感知到一个有效事件，“当前”上下文都会发生变化。 - -流水线运行上下文（Context）由六个固定的namespace组成： - -- vars，流水线变量空间（流水线静态变量全集） -- event，事件空间（事件数据全集） -- jobs，任务空间（前置已完成的任务数据） -- matrix，矩阵空间（当前矩阵参数组合分支的参数集合） -- depends，未满足的依赖事件清单（此namespace一般不会被引用） -- fulfilled，已履行的依赖事件清单（此namespace一般不会被引用） - -流水线不仅仅支持对定量的声明，流水线具备“引用”的语法特性，可以对“当前上下文”的变量进行引用，以及进行字符串拼接和python表达式运算。 - -“引用”由模式 ${{ xxxx }} 识别，通过"."的方式获取不同namespace下的所有value，支持下述两种使用方式： - -- 字符串拼接引用 - - ```yaml - # 取vars空间中的varA变量的值，并且与vars空间中的varB变量的值，最后通过"-"拼接 - key: ${{ vars.varA }}-${{ vars.varB }} - # 取当前矩阵参数组合的os、os_version、arch拼接命名 - project_name: my_project:${{ matrix.os }}:${{ matrix.os_version }}:${{ matrix.arch }} - ``` - - 对于这种拼接引用的方式，需要用户确保引用变量的值一定是字符串。如果实际的值不为字符串或者无法转换为字符串，那么采用这种引用声明的job很可能无法正常提交。 - -- 单引用 - - 单引用的情况下，引用表达式的结果可以为字符串、数字、数组（列表）或者哈希表（字典），不受类型影响。 - - ```yaml - # 取vars空间中的数组arrayA，作为key的值 - key: ${{ vars.arrayA }} - # 取前置已完成的jobA的输出result.arrayB，作为key的值 - key: ${{ jobs.jobA.result.arrayB }} - ``` - -**注意：**引用特性仅支持在defaults和overrides下使用，即jobs.xxx下的defaults和overrides或者sequence下某个job的defaults和overrides。后续演进的语法版本中将加入"在matrix中引用vars变量"的支持。 - -#### 1.8.2. python语法支持 - -对于任意引用内部而言，在引用的变量被实际的值替换后，替换后的内容将会被当作python表达式运行，如下示例： - -```yaml -# 取多个不同namespace的变量进行数值运算 -key: ${{ vars.numA + jobs.jobA.result.success_num }} - -# 调用python datetime模块，获取年月日并拼接字符串 -project_name: ${{ vars.my_name }}-${{ datetime.datetime.now().year }}-{{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }} - -# 调用字符串处理方法，对字符串进行大小写转换，split等操作 -key: ${{ vars.stringA.lower() }} -key: ${{ vars.stringA.split(':') }} - -# 单纯通过python表达式计算数值，不对变量进行引用，如计算一天一共有多少秒 -key: ${{ 24*60*60 }} -``` - -支持的非内置Python模块： - -| 模块名 | 作用 | 官方文档链接 | -| ------ | ---- | ------------ | -| re | 提供正则表达式匹配操作 | | -| math | 提供数学运算函数 | | -| time | 提供时间相关函数 | | -| datetime | 提供日期和时间处理函数 | | - -支持的安全内置Python模块： - -| 类型 | 模块名 | -| ---- | ------ | -| 数据类型 | object, bool, int, float, complex, str, bytes, bytearray, tuple, list, set, frozenset, dict | -| 数学运算 | abs, round, pow, divmod | -| 迭代器 | iter, next | -| 集合操作 | len, sum, min, max, all, any, map, filter, zip, enumerate, sorted, reversed | -| 数字转换 | bin, hex, oct | -| 字符串格式化 | ascii, repr, chr, ord, format | -| 变量和内存 | dir, locals, globals, id, hash | -| 类型检查 | isinstance, issubclass, callable | - -### 1.9. 特殊语法 - -#### 1.9.1. 具有特殊含义配置项的变量 - -**group_sync_exec_id: 1** - -字段说明：当前变量值为1时，表明每次运行流水线会同步workflow_exec.id的值给group_id这个变量，这个配置项必须在group_id变量存在的时候才起作用，不然只是一个普通变量 - -```yaml -vars: - # 当前流水线编号 - group_id: workflow_exec.200005545959096344 - group_sync_exec_id: 1 -``` - -## 2. workflow.yaml完整示例 - -以下是一个完整的workflow.yaml文件示例： - -```yaml -# 语法版本声明 -version: v1.0 - -# 流水线命名 -name: 每日构建 - -# 触发设置 -on: - # 设定定时触发事件，每天00:00触发 - - type: cron - week_day: - - Monday - - Tuesday - - Wednesday - - Thursday - - Friday - - Saturday - - Sunday - time: "00:00" - start_date: "2023-10-18" - -# 流水线变量设置 -vars: - eulermaker_account: account - eulermaker_password: passwd - os: os - os_version: version - -# 任务声明 -jobs.eulermaker-build-project:everything: - overrides: - project_name: ${{ vars.os }}-${{ vars.os_version }}:everything - build_type: full - build_arch: ${{ matrix.arch }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-build-project:epol: - overrides: - project_name: ${{ vars.os }}-${{ vars.os_version }}:epol - build_type: full - build_arch: ${{ matrix.arch }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-create-image: - overrides: - image_project_params: - pipeline_info: - pipeline_name: ${{ vars.os }}-${{ vars.os_version }}-${{ datetime.datetime.now().year }}-${{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }}-1 - group: dailybuild - category: standard - scene: cloud - image_format: qcow2 - arch: ${{ matrix.arch }} - image_config: - release_image_config: - repo_url: > - http://xxxxx/ - http://xxxx/ - http://xxx/ - http://xxxxxx/ - product: ${{ vars.os.lower() }} - version: ${{ vars.os_version }}-${{ datetime.datetime.now().year }}-${{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-build-image: - overrides: - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - pipeline_id: ${{ jobs.eulermaker-create-image.result.id }} - testbox: vm-2p8g - runtime: ${{ 24*60*60 }} - -jobs.qcow2rootfs: - overrides: - qcow2rootfs.qcow2_os: ${{ jobs.eulermaker-build-image.result.product }} - qcow2rootfs.qcow2_arch: ${{ matrix.arch }} - qcow2rootfs.qcow2_version: ${{ jobs.eulermaker-build-image.result.version }} - qcow2rootfs.qcow2_url: ${{ jobs.eulermaker-build-image.result.image_link }} - qcow2rootfs.rootfs_protocol: nfs - qcow2rootfs.rootfs_server: "172.168.131.2" - qcow2rootfs.rootfs_path: os-rw - testbox: vm-2p32g - -jobs.mugen-smoke-baseinfo: - overrides: - os: ${{ jobs.qcow2rootfs.result.os }} - os_version: ${{ jobs.qcow2rootfs.result.version }} - os_mount: nfs - arch: ${{ jobs.qcow2rootfs.result.arch }} - testbox: vm-2p8g - -jobs.mugen-smoke-basic-os: - overrides: - os: ${{ jobs.qcow2rootfs.result.os }} - os_version: ${{ jobs.qcow2rootfs.result.version }} - os_mount: nfs - arch: ${{ jobs.qcow2rootfs.result.arch }} - testbox: vm-2p8g - -# 控制流声明 -sequence: - # 矩阵声明 - matrix: - arch: - - aarch64 - - x86_64 - # 并行子结构声明 - parallel:build: - eulermaker-build-project:everything: - eulermaker-build-project:epol: - # 串行子结构声明 - sequence:create-image: - eulermaker-create-image: - eulermaker-build-image: - qcow2rootfs: - parallel:AT: - mugen-smoke-baseinfo: - mugen-smoke-basic-os: -``` - -## 3. v1.1新语法 - -### 3.1 sequence局部变量定义 - -控制流中新增对vars关键字的支持。sequence中声明的vars和一级key中vars的含义和用法完全相同，sequence中的vars存在局部作用域，并且局部作用域的优先级高于全局作用域的优先级，即声明位置越近优先级越高，常用于某些job要引用的变量与全局变量的值不同，需要覆盖全局定义变量的场景。另外，vars可以定义在任意sequence或parallel结构中。 - -优先级的说明如下示例： - -```yaml -# 全局定义的变量 -vars: - keyA: valueA - -jobs.job1: - overrides: - key1: ${{ vars.keyA }} - -jobs.job2: - overrides: - key1: ${{ vars.keyA }} - -jobs.job3: - overrides: - key1: ${{ vars.keyA }} - -sequence: - job1: - sequence:s1: - # 此处定义的vars只对sequence:s1结构生效 - vars: - keyA: valueB - job2: - parallel:p1: - # 此处定义的vars只对parallel:p1结构生效 - vars: - keyA: valueC - job3: - -# 各job变量引用的实际值： -# job1.key1 = valueA -# job2.key1 = valueB -# job3.key1 = valueC - -``` - -#### 3.2 判断job执行条件 - -在sequence中除了可以补充定义job的overrides和defaults字段外，还支持定义always、if、unless执行条件语法。 - -- always关键字 - - always用于决定job是否一定会被提交。在常规控制流的依赖关系中，如果前置job执行失败，后面依赖它的job将会阻塞不会再被提交，如果在job中声明了**always: true**，前置job运行失败或者异常，后面的任务都会被提交。 - - ```yaml - sequence: - jobA: - jobB: - # jobB运行结束，运行结果成功、失败或是异常，jobC都会被提交运行 - jobC: - always: true - - ``` - - always关键字有一种语法糖的写法：jobX！，如下示例的写法和上面yaml作用相同： - - ```yaml - sequence: - jobA: - jobB: - # jobB运行结束，运行结果成功、失败或是异常，jobC都会被提交运行 - jobC!: - - ``` - -​ 另外，如果always关键字没有声明，缺省值取false。 - -- if/unless关键字 - - if和unless关键字用于控制job是否需要被提交，如果if条件判断的结果为true，job才会被提交，否则此job将被跳过，并将job_stage设置为finish，job_health设置为skipped，unless的判断逻辑和if正好相反。 - - ```yaml - sequence: - jobA: - jobB: - if: ${{ jobs.jobA.result.id }} # 如果jobA的result.id有值，jobB会被提交，否则jobB不会被运行 - jobC: - ``` - - 如果job中没有声明关键字if，缺省值取true；如果job中always和if关键字同时存在，优先判断if关键字的执行逻辑。 - -#### 3.3 job声明不选用 - -通过jobs.jobX方式声明的job不一定全部在sequence中选用。 - -```yaml -jobs.jobA: -jobs.jobB: - -sequence: - jobB: -``` diff --git a/docs/zh/tools/devops/eulerpipeline/grammar/v1/v1.0_grammar.md b/docs/zh/tools/devops/eulerpipeline/grammar/v1/v1.0_grammar.md deleted file mode 100644 index 0a1cbb62199a2c7c6b9b62b47687a72df59ac98d..0000000000000000000000000000000000000000 --- a/docs/zh/tools/devops/eulerpipeline/grammar/v1/v1.0_grammar.md +++ /dev/null @@ -1,1065 +0,0 @@ -# 从零开始编写workflow.yaml - -workflow，即流水线，是一连串具备一定串并联关系的任务组合，描述一连串的任务之间存在的依赖关系、输入输出参数，以及整个流水线的触发条件。 - -不同版本具备不同的语法规则，从零编写和学会workflow的声明方法请详阅对应版本的文档，避免无法正常解析。 - -## 版本信息 - -| 版本 | v1.0 | -| -------- | ------------------------------------- | -| 维护者 | Ethan-Zhang() | -| 创建时间 | 2023-09-30 | -| 是否废弃 | 否 | - -## 1. 语法特性 - -流水线通过YAML描述，描述文件的YAML语法规则基于YAML 1.2版本，书写时需要基于YAML 1.2支持的书写方式进行书写。后文中提及的语法特性是描述的基于此之上的解析规则，不涉及YAML 1.2语法的说明。 - -> YAML（YAML Ain't Markup Language）是一种人类可读的数据序列化标准，它被广泛用于配置文件、数据交换语言、云计算等场景。YAML 1.2 是 YAML 的最新版本，于 2009 年发布。 -> -> 相比于之前的版本，做了一些重要的改进和修正，包括： -> -> - 更严格的类型转换规则，以避免一些常见的类型转换错误。 -> - 支持 JSON，即任何有效的 JSON 文件也是一个有效的 YAML 1.2 文件。 -> - 更好的 Unicode 支持。 -> -> YAML 1.2 的官方文档可以在以下链接找到：[YAML 1.2 官方文档](http://yaml.org/spec/1.2/spec.html)。这份文档详细地描述了 YAML 1.2 的所有特性和语法规则。 - -### 1.0. 编码风格 - -- 键命名风格 - - 为使流水线描述文档风格统一，建议所有的键命名均采用"lower_case"的命名方式，尽量不使用大写字符，如下示例： - - ```yaml - this_is_a_key: value - jobs.this_is_a_job: job - ``` - - 注意：命名风格不等于命名规则，如果不遵循建议的键命名风格并不会出现错误。 - -- 一级key声明风格 - - 一级key的含义为整个YAML文档的第一级键，虽然第一级键无论以何种顺序排列不会影响解析结果，但基于统一风格的出发点考虑，建议用户按照如下顺序对一级key进行排列，且一级key之间通过一行空行间隔，如下示例： - - ```yaml - # 版本声明，可以不存在 - version: - - # 流水线命名 - name: - - # 流水线触发设置，可以不存在 - on: - - # 流水线变量，可以不存在 - vars: - - # 流水线额外事件声明，可以不存在 - events.xxx: - - # 流水线job声明，至少需要声明一个job - jobs.xxx: - - # 流水线控制流说明 - sequence: - xxx: - ``` - - 对于本版本流水线语法而言，一级key仅识别上述6类关键字，在这七种关键字之外的一级key将被忽略。如果某个关键字不存在，比如vars，剩余关键字建议仍保持上述先后顺序排列。 - - 对于关键字的含义和详细语法说明见后文。 - -- 每行文本长度 - - 为了保持良好的可读性，建议每行文本长度不要超过**80**个字符。这是一种常见的编程规范，可以使代码在大多数编辑器和终端中看起来更清晰。但这并不是强制性的规定，根据实际情况和个人习惯，可以适当调整。 - - 对于长文本，可以利用YAML的特性转行声明，如下示例： - - ```yaml - # 通过"|"语法保留换行符"\n" - key: | - this is a long long story, - you could learn it step by step. - # key = "this is a long long story,\nyou could learn it step by step." - - # 通过"|+"语法保留所有换行符"\n" - key: |+ - this is a long long story, - you could learn it step by step. - - - # key = "this is a long long story,\nyou could learn it step by step.\n\n\n" - - # 通过"|-"语法，去除末尾换行符"\n" - key: |- - this is a long long story, - you could learn it step by step. - - - # key = "this is a long long story,\nyou could learn it step by step." - - # 通过">"语法，虽然内容书写存在换行，但解析后的内容去除换行，以空格代替 - key: > - https://repo1/ - https://repo2/ - # key = "https://repo1/ https://repo2" - ``` - - 更多的说明请参考YAML1.2官方文档（见 **章节1. 语法特性** 开头） - -### 1.1. 基本声明 - -基本声明包含**version**与**name**两个一级key，前者用以锚定语法解析版本，后者用以标识流水线名称。 - -#### 1.1.1. 语法版本声明 - -workflow支持多版本语法解析，对于不声明version的workflow而言，采用默认版本语法（v1.0）进行解析。 -声明版本通过关键字version定义： - -```yaml -# 一般情况下，version会被声明在workflow.yaml的顶部 -# 但version的位置并不会影响解析，确保version并非嵌套于其他key下即可 - -version: v1.0 -``` - -根据声明的version的不同，请查阅不同版本的语法特性介绍。 - -#### 1.1.2. 流水线命名 - -无论在什么版本，workflow的名字均由name字段定义。流水线的名字不要求唯一，可以是任意**字符串**。 - -name为一定需要定义的key，如果流水线yaml中缺少这个key解析器将不予通过。 - -```yaml -version: v1.0 - -name: my workflow -``` - -### 1.2. 触发条件定义 - -#### 1.2.1. workflow支持三种触发方式 - -- 手动触发： 基本的触发方式，不传递触发事件数据的方式，触发后将提交所有不存在依赖的任务 -- 定时触发： 周期性自动触发方式，通过设定时间条件，系统自动触发。 -- webhook触发： git仓库配置服务的webhook回调地址等信息，通过webhook回调请求自动触发。 - - 定时触发和webhook触发方式通过关键字"on"定义，如果不需要这两种触发方式，on可以不声明。 - - 示例： - -```yaml - version: v1.1 - - name: workflow - - on: - # webhook触发事件定义 - - type: webhook/pr - git_repo: https://gitee.com/openeuler/radiaTest.git - branch: master - # 定时触发事件定义 - - type: cron - crontab: 0 15 10 ? * MON-FRI - - other_keys: other_values -``` - -#### 1.2.2. webhook触发 - - webhook事件分为webhook/pr，webhook/push，webhook/note，webhook/issue四种类型。 - -- PullRequest类事件 - - 声明的事件键值对必须包含type(webhook/pr)，git_repo(仓库地址)，branch(仓库分支)，action(场景，共8类) - - 即当对应的仓库分支存在PullRequest相关事件时，均会触发此流水线，包括新建PR/删除PR/合入PR/...等事件。 - - 如果需要对PR事件进行更细致的筛选，用户可以指定action进行过滤。 - -- Push类事件 - - 声明的事件键值对必须包含type(webhook/push)，git_repo(仓库地址)，branch(仓库分支) - - 即当对应的仓库分支被推送更新后，均会触发此流水线。 - -- 评论类事件 - - 声明的事件键值对必须包含type(webhook/note)，git_repo(仓库地址)，branch(仓库分支,仅支持PullRequest场景存在)，notable_type(评论主体)，notes(评论钩子) - - 即当对应的仓库分支的指定被评论主体（如PullRequest作为被评论主体）并且评论内容能够匹配评论钩子时，会触发此流水线。 - -- Issue类事件 - - 声明的事件键值对必须包含type(webhook/issue)，git_repo(仓库地址)，state(问题单状态) - - 即当对应的仓库分支存在Issue相关事件时，均会触发此流水线，包括新建issue/删除issue/...等事件。 - - state提供了对issue的场景细分能力，通过配置状态可以拆分不同场景。 - - webhook事件的声明支持矩阵式声明方式，从而帮助减少重复描述，如下所示： - -```yaml -on: - - type: webhook/note - git_repo: https://gitee.com/openeuler/radiaTest.git - branch: - - master - - dev - - test - notable_type: - - PullRequest - notes: - - /retry - - /retest -``` - -这个例子意味着多个分支下的PullReques被评论了"/retry"或"/retest"都会触发此流水线 - -以上关于webhook讲解较为粗略，建议阅读更详细的webhook配置文档，以便更好的使用: - - - -特别说明: 如果不仅仅需要触发，还需要在流水线中引用（该特性将在后文详述）触发事件中的字段，建议编辑者通过查阅不同git仓库的webhook文档了解。 - -1. Gitee: - -2. Github: - -3. Gitlab: - -#### 1.2.3. 定时触发事件 - - 当配置的触发事件type字段为[cron，interval，date]值时，说明该事件为定时事件，对于某一个定时任务，type仅可为其中某一个取值，以下为简单示例： - -```yaml -on: - - type: cron - crontab: 0 15 10 ? * MON-FRI - - type: interval - seconds: 60 - - type: date - run_date: 2024-01-01 00:00:00 - - type: date - run_date: 164900500 -``` - -以上配置，意味着时间满足任意一个场景时，流水线被执行。 - -关于三种类型的定时参数，参看以下官方文档配置即可: - - - - - - - -### 1.3. 流水线全局变量定义 - -流水线的全局变量通过vars字段声明，当前版本支持字符串、数组、对象（字典/哈希表）三种格式。 - -```yaml -version: v1.0 - -name: workflow - -vars: - # 字符串 - varA: string - # 数组 - varB: - - elementA - - elementB - # 对象（支持多级结构嵌套） - varC: - keyA: valueA - # 嵌套数组 - keyB: - - valueB1 - - valueB2 - # 嵌套对象 - keyC: - keyC1: -``` - -流水线变量定义的目的在于定义整个流水线可以利用的若干变量（常量），定义后的变量可以被流水线任意阶段任务引用，从而避免每个任务对于该变量的重复冗余声明。 - -举例而言，假设某个流水线的10个任务均需要上述案例的varB变量作为Input（输入/入参），则只需要引用varB赋予给对应参数即可。 - -具体的引用方式详见后文对于引用语法的介绍。 - -如果一个流水线不需要定义任何流水线变量时，vars关键字可以不存在: - -```yaml -version: v1.0 - -name: workflow - -other_keys: other_values -``` - -### 1.4. 额外事件声明 - -如果流水线内部的某个任务除了依赖于前置的任务外，还实际依赖于额外的webhook事件，或者依赖于一些额外的事件，则需要对这些额外的事件进行预声明。 - -用户通过events.xxx模式的key进行额外事件的声明，"xxx"为额外事件的命名。 - -**注意：**大多数情况下，用户不需要定义额外事件。额外事件不支持定时以及手动事件声明。 - -#### 1.4.1. webhook事件 - -当定义额外webhook事件时，该事件需求定义的key-values与上文流水线触发设置中介绍的一致，如下示例： - -```yaml -version: v1.0 - -name: workflow - -vars: - -events.eventA: - type: webhook/pr - git_repo: https://gitee.com/openeuler/repository.git - branch: - - master - - dev -``` - -#### 1.4.2. job事件 - -除了webhook事件外，额外事件可以定义一种新的事件类型，即job类型事件。job类型事件分为stage和step两个子类，如下示例： - -```yaml -version: v1.0 - -name: workflow - -vars: - -# 额外事件A - jobA进入boot阶段 -events.eventA: - type: job/stage - job: jobA - job_stage: boot - -# 额外事件B - jobA进入名为testcase001的步骤 -events.eventB: - type: job/step - job: jobA - job_step: testcase001 - -# 额外事件C - jobA进入finish阶段且incomplete -events.eventC: - type: job/stage - job: jobA - job_stage: finish - job_health: incomplete -``` - -job类型的事件除了type和job必填外，其他字段可以根据需求从job类型事件的全集keys中选取（job_stage/job_health/job_step/nickname）。 - -定义后的job类型事件如何使用见后文任务定义和控制流声明章节。 - -### 1.5. 任务定义 - -#### 1.5.1. 基础概念 - -对于所有流水线涉及的任务，都需要通过jobs.xxx模式的一级key进行一次声明，主要目的为定义任务的Input（输入/入参），且每个被声明job的value均要求为对象（字典/哈希表）格式（或者为空）。 - -jobs.xxx类关键字常见的两种二级关键字为**defaults**和**overrides**，这两个二级key可以不声明，但如果具备value，则value必须为对象（字典/哈希表）格式，用以声明待提交的job即为模板所具备的所有参数。 - -如下所示： - -```yaml -name: workflow - -vars: - -# 空value的job缺省声明 -jobs.jobA: - -# 空defaults value, 空overrides value声明 -jobs.jobB: - defaults: - overrides: - -# 缺省defaults，overrides非空声明 -jobs.jobB: - overrides: - # 字符串 - keyA: valueA - # 数组 - keyB: - - valueB1 - - valueB2 - # 对象（支持多级嵌套） - keyC: - keyC1: valueC1 - keyC2: - - valueC2 -``` - -除了嵌套的声明方式，流水线语法支持扁平化的方式减少声明的难度，如下示例： - -```yaml -jobs.jobB: - overrides: - keyC.keyC1: valueC1 - -# 等价于 -jobs.jobB: - overrides: - keyC: - keyC1: valueC1 -``` - -**注意：**这种等价仅于defaults和overrides下有效。 - -defaults和overrides意义如字面含义所示，defaults中定义的key-values如果原job中存在对应key，则以原job中的value为实际提交value；overrides中定义的key-values将无条件覆盖到原job的值提交。 - -对于job的概念，以及原job.yaml的内容，建议查阅compass-ci/lkp-tests的文档进行了解： - -1. 如何向compass-ci/lkp-tests新增job: -2. job的定义: -3. job示例: - -#### 1.5.2. 任务别名定义 - -通常情况下，jobs.xxx模式中xxx即为被声明的job名，如如果计划声明一个ltp-bm的任务，则声明jobs.ltp-bm。但在某些流水线中，可能同一个任务需要运行多次，且任务实际的入参并不相同，因此设计多次声明的可能。在这种情况下，则需要利用"别名"语法特性。 - -别名的声明方式如下示例： - -```yaml -jobs.ltp-bm:first-ltp-bm: - -jobs.ltp-bm:second-ltp-bm: -``` - -这两个被声明的任务实际指向的都是ltp-bm这同一个job，但是因为别名所以流水线会将其看作两个不同的个体。 - -#### 1.5.3. 额外事件依赖声明 - -除了defaults和overrides两种常用的二级keys外，jobs.xxx还支持声明depends字段，本字段用以声明额外依赖（额外事件，即上文**章节1.3**内容的应用） - -```yaml -events.eventA: - xxx: xxx - -events.eventC: - xxx: xxx - -jobs.jobA: - defaults: - default_keyA: valueA - overrides: - override_keyB: valueB - depends: - # 额外依赖于上文中通过events.eventA声明的事件 - # 只需要写key:的形式，不需要填value，填了也会被忽略 - eventA: - # 且额外依赖于上文中通过events.eventC声明的事件 - eventC: -``` - -对于jobA而言，depends字段相当于定义了若干AND逻辑关系的额外依赖，当且仅当所有依赖的事件均发生后jobA才会被提交执行。 - -当depends不声明的时候，jobA的依赖仅取决于其处于控制流的位置（详见后文控制流声明），否则为控制流依赖于额外依赖的逻辑与结果。 - -```yaml -submit_jobA = [jobA's depends parsed from controlflow] AND [jobA's depends defined from 'depends'] -``` - -### 1.6. 控制流声明 - -#### 1.6.1. 基础特性 - -流水线任务的串并行结构通过控制流声明对已通过一级key”jobs.xxx“预声明的各个任务进行编排，通过一级key“sequence”定义，如下所示： - -```yaml -version: v1.0 - -name: workflow - -# jobA:first进入boot阶段 -events.eventA: - type: job/stage - job: jobA - nickname: first - job_stage: boot - -# 定义别名为first的jobA -jobs.jobA:first: - overrides: - -jobs.jobB: - overrides: - # 额外依赖于"jobA:first进入boot阶段"事件 - depends: - eventA: - -# 控制流声明 -sequence: - # 声明并行子结构 - parallel: - # jobA:first和jobB并行 - jobA:first: - jobB: -``` - -控制流声明中，存在sequence、parallel、matrix三种关键字，除了关键字外，所有key都会被认作对已预声明的job的引用。对于所有job的引用，需要确保引用的job全称（包含别名）在流水线一级key中存在（以jobs.xxx预声明）。如果sequence中引用了jobA，但流水线一级key中缺少jobs.jobA这个key，解析器将不会给予通过。 - -**注意：**控制流声明的根（一级key）必须为sequence。 - -- 关键字sequence - - sequence意在声明一个串行结构，在sequence下的所有key将被解析为按声明顺序（从上到下）排列的一连串成员，每一个成员必然依赖于其上面一个的成员。 - - ```yaml - sequence: |---------| |---------| - jobA: = | jobA | =========> | jobB | - jobB: |---------| |---------| - ``` - - sequence和job一样，可以通过sequence:xxx:的方式定义别名，该别名仅在一级串行子结构中存在实际意义，非一级子结构的别名仅起标识作用，具体参考下文stage声明说明。 - - ```yaml - # 根sequence，不可添加别名，为控制流声明关键字 - sequence: - # 一级串行子结构，别名为seqA - sequence:seqA: - # 二级串行子结构，别名为seqB - sequence:seqB: - ``` - - 如上所示，sequence的key并不一定只能是job，当sequence内部的key同样是sequence时，意味着串行结构的嵌套。当然，对于纯sequence的嵌套是不具备实际意义的，仅为分组标识，单纯的串行嵌套相当于没有嵌套。 - - ```yaml - sequence: < - - - - - seqA - - - - - - > - sequence:seqA: |---------| |---------| |---------| - jobA: = | jobA | =========> | jobB | =========> | jobC | - jobB: |---------| |---------| |---------| - jobC: - ``` - -- 关键字parallel - - parallel意在声明一个并行结构，在parallel下的所有key将被解析为并列的若干成员，每一个成员都依赖于整个parallel都前置依赖，互相之间不存在控制流定义的依赖关系（可以存在通过depends额外声明的依赖，额外跳线依赖不被控制流声明控制） - - ```yaml - ___________|___________ - sequence: | | - parallel: |---------| |---------| - jobA: = | jobA | | jobB | - jobB: |---------| |---------| - |______________________| - | - ``` - - 注意，parallel一定不可以声明在workflow.yaml的一级key，对于控制流声明而言，根key一定是sequence。 - - 和sequence一致，parallel也可以以parallel:xxx:的方式定义别名，该别名同样仅在一级并行子结构中存在实际含义，非一级子结构的别名仅起标识作用，具体参考下文stage声明说明。 - - 同理，单纯的并行嵌套相当于没有嵌套，如下示例，等价于jobA、jobB、jobC三者并行。 - - ```yaml - ___ _________________|_______________ - sequence: | | _________|__________ ___ - parallel:prlA: | |---------| |----|----| |----|----| | - jobA: = prlA | jobA | | jobB | | jobC | prlB - parallel:prlB: | |---------| |----|----| |----|----| | - jobB: | | |__________________| _|_ - jobC: _|_ |_______________________________| - | - ``` - -#### 1.6.2. job的补充声明 - -由上文可知，job无论是defaults、overrides还是depends的声明，可以声明在jobs.xxx这个key之下，这也是比较推荐的用法。但其实在控制流声明中，用户可以对job进行补充声明，补充的声明将深层update到预定义的job声明中，如下所示： - -```yaml -name: workflow - -jobs.jobA: - defaults: - keyA: valueA - overrides: - keyB: - keyB1: valueB1 - keyB2: - keyB21: valueB21 - -sequence: - jobA: - overrides: - # 与上文中jobs下的overrides特性相同 - # 采用keyB.keyB2.keyB21和keyB.keyB2.keyB22为key，即 - # keyB.keyB2.keyB21: valueB21_new - # keyB.keyB2.keyB22: valueB22 - # 与下述声明方式等价 - keyB: - keyB2: - keyB21: valueB21_new - keyB22: valueB22 -``` - -在这个例子中，sequence中将jobA的预定义的overrides下的keyB21重新定义为valueB2_new，且在keyB2下新创建了一个keyB22的键值对。 - -补充声明特性以对象（字典/哈希表）的递归update实现，一定为控制流中的定义覆写jobs的预定义。 - -### 1.7. 流水线阶段(stage)声明 - -在**章节1.6. 控制流声明**中有提及，无论是sequence还是parallel分别可以通过sequence:xxx:和parallel:xxx:的形式声明别名。流水线web服务将基于下述规则划分控制流的不同阶段，规则如下所示： - -```yaml -1. 当且仅当sequence和parallel为根sequence下的一级结构时，其别名等同于阶段名。 -2. 当根sequence下存在job名时（非sequence也非parallel），该job以自身job的别名作为阶段名（若无别名则以job名）独立被识别为一个阶段。 -3. 阶段存在向后包裹的特点，直到下一个有效阶段声明前，所有结构属于同一个阶段。 -3. 沿着根sequence向下检索，在遇到第一个有效的stage命名之前，所有的结构均属于“未命名”阶段。 -sequence: - 阶段(stage) - parallel: ——｜ - job0: > 未命名 - job1: ——｜ - - job2:build-job: —— > build-job - - jobA: ——｜ - sequence: > jobA - jobB: ——｜ - - parallel:prlA: ——｜ - jobC: ｜ - jobD: ｜ - sequence:seqB: > prlA - jobE: ｜ - jobF: ——｜ - - sequence:seqC: —— > seqC - jobG: ——｜ -``` - -p.s. 阶段仅会影响web端的渲染，控制流的实际意义不依赖于阶段的定义，换而言之，如果不考虑可视化的便利性，可以不对阶段命名深究。 - -### 1.8. Matrix语法特性 - -#### 1.8.1. 基本概念 - -用户可以在控制流**串行结构的任意位置**可以插入一个matrix关键字，用以混入(Mixin)局部的矩阵(参数组合)，从而改变后续任务的上下文(Context)。 - -matrix关键字同样可以声明别名，用以避免对象（字典/哈希表）的重key异常，但除了区别外没有实际意义。 - -**注意：** matrix不能直接声明在parallel关键字下，只能声明在sequence关键字下。 - -matrix的声明结构一定为如下格式: - -```yaml -sequence: - matrix: - paramA: - - valueA1 - - valueA2 - - valueAn - paramB: - - valueB1 - - valueB2 -``` - -即，matrix是一个对象（字典/哈希表），且所有一级value均为数组（列表）。 - -上述例子中matrix的含义为，对所处位置的流水线上下文混入矩阵，其中paramA有三种可能的取值，paramB有两种可能的取值，即共3*2共6种取值组合。 - -```yaml -matrix: _ - paramA: | 1. paramA = valueA1; paramB = valueB1 - - valueA1 | 2. paramA = valueA1; paramB = valueB2 - - valueA2 | 3. paramA = valueA2; paramB = valueB1 - - valueAn => { 4. paramA = valueA2; paramB = valueB2 - paramB: | 5. paramA = valueAn; paramB = valueB1 - - valueB1 |_ 6. paramA = valueAn; paramB = valueB2 - - valueB2 -``` - -当流水线上下文混入(Mixin)一个局部的矩阵后，流水线的上下文将会根据参数取值组合的种数裂解成多个“分支”，每一个“分支”的上下文依据其中一种取值组合。当这个分支之后的任务直接引用上下文中的paramA时，会根据当前上下文的paramA取值，后续任务的驱动也会与其他”分支“独立。 - -举例而言： - -```yaml -sequence: - jobA: - parallel: - jobB: - sequence: - matrix: - arch: - - aarch64 - - x86_64 - jobC: - jobD: -``` - -根据 **章节1.5. 控制流声明** 的介绍，不难看出，这个描述声明的结构如下： - -```yaml - ________ - | | - |-------| jobB |----------------------------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | - | / \ | | | - |-------| matrix |-------| jobC |---------| - \ / |________| - 1. arch = aarch64; - 2. arch = x86_64 -``` - -对于jobA和jobB，如果他们在被提交的时候引用“当前上下文”（所谓当前为被提交的时间点）中的arch变量，他们将取不到任何值。 - -p.s. 关于引用的概念详见**章节1.6.** - -而对于jobC和jobD而言，他们实际上被裂解到了并行的两个“分支”上，其中一个分支上下文中的arch是aarch64而另一个分支上的arch是x86_64，即上述控制流结构等价于： - -```yaml -1. arch = aarch64; - ________ - | | - |----------| jobB |---------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | aarch64 - | | | | - |----------| jobC |---------| - |________| - aarch64 - -2. arch = x86_64 - ________ - | | - |----------| jobB |---------| - | |________| | - ________ | | ________ - | | | | | | --------| jobA |-------| |-------| jobD |--------> - |________| | | |________| - | ________ | x86_64 - | | | | - |----------| jobC |---------| - |________| - x86_64 -``` - -这两个矩阵参数组合“分支”共享jobA和jobB的前置依赖，但aarch64的jobD只会依赖于aarch64的jobC，即各分支依赖独立。 - -这样避免了在很多场景下的相同结构的重复声明。 - -#### 1.8.2. 矩阵x矩阵 - -流水线控制流支持多matrix在不同位置声明，在这种情况下，下文矩阵受到上文矩阵影响，下文矩阵实际为上下文矩阵相乘的结果，如下示例: - -```yaml -sequence: - matrix:m1: - os: - - openeuler - os_version: - - 20.03 - - 22.03-LTS - jobA: - matrix:m2: - arch: - - aarch64 - - x86_64 - jobB: -``` - -对于这个例子而言，jobA共有两种上下文分支，而jobB共有4种，如下所示： - -```yaml - ________ ________ - | | | | ---------------| jobA |-----------------------------------------| jobB |-----------------------> - |________| |________| - 1. os=openeuler; os_version=20.03 1. os=openeuler;os_version=20.03;arch=aarch64; - 2. os=openeuler; os_version=22.03-LTS 2. os=openeuler;os_version=20.03;arch=x86_64; - 3. os=openeuler;os_version=22.03-LTS;arch=aarch64; - 4. os=openeuler;os_version=22.03-LTS;x86_64; -``` - -因此对于声明此例控制流的关于jobA和jobB的流水线，实际jobA将会被提交两次，jobB将会被提交4次，jobB的1和2分支依赖于jobA的1分支，jobB的3和4分支依赖于jobA的2分支，jobB的最终参数组合即jobA之前声明的matrix与jobB之前的matrix相乘的结果。 - -#### 1.8.3. excludes语法特性 - -matrix支持通过excludes声明排除特定的组合，如下所示： - -```yaml -sequence: - matrix: - os: - - openeuler - - centos - os_version: - - "20.03" - - 7 - excludes: - # 下述两种描述形式均可支持 - - {"os": "openeuler", "os_version": "7"} - - os: centos - os_version: "20.03" -``` - -此声明方式意为此矩阵只存在两种参数组合，即 ”os=openeuler;os_version=20.03“ 和 “os=centos;os_version=7”。 - -#### 1.8.4. 参数组合语法糖 - -同时，matrix具备一种简化excludes声明的语法糖"|"，以上述样例可以改写为： - -```yaml -sequence: - matrix: - os|os_version: - - openeuler | 20.03 #有无空格或者制表符均支持 - - centos | 7 #推荐以制表符分隔，这样的声明较为直观 -``` - -### 1.9. "引用"表达式声明 - -#### 1.9.1. 基本概念 - -对于一条正在运作的流水线而言，其上下文是动态的，每执行完成一个任务，每感知到一个有效事件，“当前”上下文都会发生变化。 - -流水线运行上下文（Context）由六个固定的namespace组成： - -- vars，流水线变量空间（流水线静态变量全集） -- event，事件空间（事件数据全集） -- jobs，任务空间（前置已完成的任务数据） -- matrix，矩阵空间（当前矩阵参数组合分支的参数集合） -- depends，未满足的依赖事件清单（此namespace一般不会被引用） -- fulfilled，已履行的依赖事件清单（此namespace一般不会被引用） - -流水线不仅仅支持对定量的声明，流水线具备“引用”的语法特性，可以对“当前上下文”的变量进行引用，以及进行字符串拼接和python表达式运算。 - -“引用”由模式 ${{ xxxx }} 识别，通过"."的方式获取不同namespace下的所有value，支持下述两种使用方式： - -- 字符串拼接引用 - - ```yaml - # 取vars空间中的varA变量的值，并且与vars空间中的varB变量的值，最后通过"-"拼接 - key: ${{ vars.varA }}-${{ vars.varB }} - # 取当前矩阵参数组合的os、os_version、arch拼接命名 - project_name: my_project:${{ matrix.os }}:${{ matrix.os_version }}:${{ matrix.arch }} - ``` - - 对于这种拼接引用的方式，需要用户确保引用变量的值一定是字符串。如果实际的值不为字符串或者无法转换为字符串，那么采用这种引用声明的job很可能无法正常提交。 - -- 单引用 - - 单引用的情况下，引用表达式的结果可以为字符串、数字、数组（列表）或者哈希表（字典），不受类型影响。 - - ```yaml - # 取vars空间中的数组arrayA，作为key的值 - key: ${{ vars.arrayA }} - # 取前置已完成的jobA的输出result.arrayB，作为key的值 - key: ${{ jobs.jobA.result.arrayB }} - ``` - -**注意：**引用特性仅支持在defaults和overrides下使用，即jobs.xxx下的defaults和overrides或者sequence下某个job的defaults和overrides。后续演进的语法版本中将加入"在matrix中引用vars变量"的支持。 - -#### 1.9.2. python语法支持 - -对于任意引用内部而言，在引用的变量被实际的值替换后，替换后的内容将会被当作python表达式运行，如下示例： - -```yaml -# 取多个不同namespace的变量进行数值运算 -key: ${{ vars.numA + jobs.jobA.result.success_num }} - -# 调用python datetime模块，获取年月日并拼接字符串 -project_name: ${{ vars.my_name }}-${{ datetime.datetime.now().year }}-{{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }} - -# 调用字符串处理方法，对字符串进行大小写转换，split等操作 -key: ${{ vars.stringA.lower() }} -key: ${{ vars.stringA.split(':') }} - -# 单纯通过python表达式计算数值，不对变量进行引用，如计算一天一共有多少秒 -key: ${{ 24*60*60 }} -``` - -支持的非内置Python模块： - -| 模块名 | 作用 | 官方文档链接 | -| -------- | ---------------------- | ----------------------------------------------- | -| re | 提供正则表达式匹配操作 | | -| math | 提供数学运算函数 | | -| time | 提供时间相关函数 | | -| datetime | 提供日期和时间处理函数 | | - -支持的安全内置Python模块： - -| 类型 | 模块名 | -| ------------ | ------------------------------------------------------------ | -| 数据类型 | object, bool, int, float, complex, str, bytes, bytearray, tuple, list, set, frozenset, dict | -| 数学运算 | abs, round, pow, divmod | -| 迭代器 | iter, next | -| 集合操作 | len, sum, min, max, all, any, map, filter, zip, enumerate, sorted, reversed | -| 数字转换 | bin, hex, oct | -| 字符串格式化 | ascii, repr, chr, ord, format | -| 变量和内存 | dir, locals, globals, id, hash | -| 类型检查 | isinstance, issubclass, callable | - -### 1.10. 特殊语法 - -#### 1.10.1. 具有特殊含义配置项的变量 - -**group_sync_exec_id: 1** - -字段说明：当前变量值为1时，表明每次运行流水线会同步workflow_exec.id的值给group_id这个变量，这个配置项必须在group_id变>量存在的时候才起作用，不然只是一个普通变量 - -```yaml -vars: - # 当前流水线编号 - group_id: workflow_exec.200005545959096344 - group_sync_exec_id: 1 -``` - -## 2. workflow.yaml完整示例 - -以下是一个完整的workflow.yaml文件示例： - -```yaml -# 语法版本声明 -version: v1.0 - -# 流水线命名 -name: 每日构建 - -# 触发设置 -on: - # 设定定时触发事件，每天00:00触发 - - type: cron - week_day: - - Monday - - Tuesday - - Wednesday - - Thursday - - Friday - - Saturday - - Sunday - time: 00:00 - start_date: 2023-10-18 - -# 流水线变量设置 -vars: - eulermaker_account: account - eulermaker_password: passwd - os: os - os_version: version - -# 任务声明 -jobs.eulermaker-build-project:everything: - overrides: - project_name: ${{ vars.os }}-${{ vars.os_version }}:everything - build_type: full - build_arch: ${{ matrix.arch }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-build-project:epol: - overrides: - project_name: ${{ vars.os }}-${{ vars.os_version }}:epol - build_type: full - build_arch: ${{ matrix.arch }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-create-image: - overrides: - image_project_params: - pipeline_info: - pipeline_name: ${{ vars.os }}-${{ vars.os_version }}-${{ datetime.datetime.now().year }}-${{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }}-1 - group: dailybuild - category: standard - scene: cloud - image_format: qcow2 - arch: ${{ matrix.arch }} - image_config: - release_image_config: - repo_url: > - http://xxxxx/ - http://xxxx/ - http://xxx/ - http://xxxxxx/ - product: ${{ vars.os.lower() }} - version: ${{ vars.os_version }}-${{ datetime.datetime.now().year }}-${{ datetime.datetime.now().month }}-${{ datetime.datetime.now().day }} - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - testbox: vm-2p8g - -jobs.eulermaker-build-image: - overrides: - secrets: - ACCOUNT: ${{ vars.eulermaker_account }} - PASSWORD: ${{ vars.eulermaker_password }} - pipeline_id: ${{ jobs.eulermaker-create-image.result.id }} - testbox: vm-2p8g - runtime: ${{ 24*60*60 }} - -jobs.qcow2rootfs: - overrides: - qcow2rootfs.qcow2_os: ${{ jobs.eulermaker-build-image.result.product }} - qcow2rootfs.qcow2_arch: ${{ matrix.arch }} - qcow2rootfs.qcow2_version: ${{ jobs.eulermaker-build-image.result.version }} - qcow2rootfs.qcow2_url: ${{ jobs.eulermaker-build-image.result.image_link }} - qcow2rootfs.rootfs_protocol: nfs - qcow2rootfs.rootfs_server: "172.168.131.2" - qcow2rootfs.rootfs_path: os-rw - testbox: vm-2p32g - -jobs.mugen-smoke-baseinfo: - overrides: - os: ${{ jobs.qcow2rootfs.result.os }} - os_version: ${{ jobs.qcow2rootfs.result.version }} - os_mount: nfs - arch: ${{ jobs.qcow2rootfs.result.arch }} - testbox: vm-2p8g - -jobs.mugen-smoke-basic-os: - overrides: - os: ${{ jobs.qcow2rootfs.result.os }} - os_version: ${{ jobs.qcow2rootfs.result.version }} - os_mount: nfs - arch: ${{ jobs.qcow2rootfs.result.arch }} - testbox: vm-2p8g - -# 控制流声明 -sequence: - # 矩阵声明 - matrix: - arch: - - aarch64 - - x86_64 - # 并行子结构声明 - parallel:build: - eulermaker-build-project:everything: - eulermaker-build-project:epol: - # 串行子结构声明 - sequence:create-image: - eulermaker-create-image: - eulermaker-build-image: - qcow2rootfs: - parallel:AT: - mugen-smoke-baseinfo: - mugen-smoke-basic-os: -```