发布基础设施
发布基础设施¶
当发布被批准时会发生什么？发布基础设施分为两个步骤，由不同的但相关的事件触发。
第一步是由发布请求合并到发布仓库中触发的，启动发布仓库“post”流水线中的一系列任务。
Release request merged
|
+-------v-----------------------+
Post pipeline (releases repo)
+---+-----------------------+---+
| |
v v
+-------+-------+ +-------+-------+
| tag | | publish-docs |
| | | |
| (pushes tags | | (to releases |
| to each repo) | | website) |
| | | |
+-------+-------+ +---------------+
第二步是由标签的创建触发的，在标签着陆的仓库中创建“tag”流水线和“release”流水线（或针对 beta 版本的“pre-release”流水线）中的一系列任务。
Tag is created -----------------------------------------------
| |
+----v------------------------------------+ +----------v-----------+
Release pipeline (each repo) Tag pipeline (each repo)
+----+---------------+---------------+----+ +----------------------+
| | | |
v v v v
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| release | | announce | | propose | | publish |
| | | | |constraints| | release |
|(builds | | (sends | | update | | notes |
| tarball | | email) | | | | |
| & uploads | | | +-----------+ +-----------+
| it) | +-----------+
+-----------+
请注意，单个发布请求可以在不同的仓库中创建多个标签，从而在多个仓库中触发第二阶段。
发布流水线中的任务需要来自发布请求的信息（例如系列名称，或是否上传到 pypi）。我们使用 git 标签本身中的元数据来传递这些信息：第一步中的“tag”任务将信息记录在标签中，第二步中的任务直接从标签中检索这些信息。
除非另有说明，本文档根据知识共享署名3.0许可协议授权。请参阅所有OpenStack法律文件。