ursa-major 0.5.1

标签配置文件

Ursa-Major使用的标签配置文件是json格式，顶级键是我们应该将模块标签添加到其继承中的koji标签。对于每个标签，它包含一个模块列表，维护者还可以为标签设置所有者。

一个示例标签配置文件如下

{
    "fedora-30-buildroot-modules": {
        "modules": [
            {
                "name": "httpd",
                "priority": 10,
                "buildrequires": {
                    "platform": "f30"
                },
                "requires": {
                    "platform": "f30"
                },
                "stream": "2.4"
            },
            {
                "name": "ruby",
                "priority": 40,
                "requires": {
                    "platform": "f30"
                },
                "stream": "2.5"
            }
        ],
        "owners": [
            "foo@example.com"
        ]
    },
    "fedora-30-test-build": {
        "modules": [
            {
                "name": "testmodule",
                "priority": 150,
                "stream": "f30"
            }
        ],
        "owners": [
            "bar@example.com"
        ]
    }
}

有效的模块配置应包含

• name (必需)：模块名称

• stream (必需)：模块流

• 优先级 (必填): 使用此优先级将模块标签添加到标签继承中

• requires (可选): 模块的运行时依赖。

• buildrequires (可选): 模块的构建时依赖。

对于每个标签，所有者可以通过电子邮件地址进行设置。

Ursa-Major使用的默认标签配置文件是当前工作目录中的ursa-major.json。您可以使用--tag-config-file来更改它。

Koji和MBS

标签配置文件中的标签是koji标签，Ursa-Major连接到koji hub并按配置更新标签继承，并连接到MBS以查询模块信息，特别是模块md数据。

Koji和MBS服务器设置在Ursa-Major的配置文件中，默认的全局配置文件是/etc/ursa-major/ursa-major，可以通过--config参数更改。用户配置文件是~/.config/ursa-major/ursa-major.conf，可以通过--user-config更改。用户配置文件是可选的，全局配置文件中的值将被用户配置文件覆盖。

示例配置文件

$ cat /etc/ursa-major/ursa-major.conf

[main]
# See https://docs.pythonlang.cn/3/library/logging.html#logging-levels
log_level = info

[koji]
profile = koji

[mbs]
server_url = https://mbs.fedoraproject.org/

[mail]
mail_processing = true
mail_log_level = info
mail_server = smtp.example.com
mail_from = ursa-major@example.com
mail_replyto = ursa-major@example.com
# email addresses seperated by ','
mail_always_cc = ursa-major-admin@example.com
mail_always_bcc =
mail_subject_prefix = [ursa-major]

show-config

这仅显示标签配置文件的内容，或指定标签的内容。

参数

• --tag (可选): 仅显示此标签下的配置内容

示例

$ ursa-major show-config --tag-config-file ~/fedora-prod-ursa-major.json --tag fedora-30-test-build

check-config

检查标签配置文件以检测任何无效配置

$ ursa-major check-config --tag-config-file ~/fedora-prod-ursa-major.json

检查包括

• name、stream和priority是模块的必填项

• priority值不应与其他父标签冲突，这些父标签不属于此模块的标签继承

• …

remove-module

从标签配置文件中删除一个模块。

参数

• --tag (必填): 从此标签删除模块

• --name (必填): 模块名称

• --stream (必填): 模块stream

• --require (可选): 模块的运行时requires，可以指定多次

• --buildrequire (可选): 模块的buildrequires，可以指定多次

示例

$ ursa-major remove-module --tag fedora-30-test-build --name testmodule --stream f30

如果模块testmodule:f30在标签fedora-30-test-build下存在，则将从标签配置文件中删除该模块。

add-module

在指定标签下将模块添加到标签配置文件。

参数

• --tag (必填): 将模块添加到此标签

• --name (必填): 模块名称

• --stream (必填): 模块stream

• --priority (必填): 将标签添加到继承时的优先级值

• --require (可选): 模块的运行时requires，可以指定多次

• --buildrequire (可选): 模块的buildrequires，可以指定多次

示例

$ ursa-major add-module --tag fedora-30-test-build --name testmodule --stream f30 --priority 100

如果指定的模块（具有该name和stream）已存在于标签配置文件中，Ursa-Major将检查requires或priority是否与命令行中指定的值不同，如果是，则将更新标签配置文件以使用指定的值。

update-tag

使用标签配置中所有模块的最新构建标签更新标签的继承数据。

参数

• --tag (必选): 要更新的标签

• --wait-regen-repo (可选): 等待 regen-repo 任务完成

示例

$ ursa-major update-tag --tag fedora-30-test-build --wait-regen-repo

这将检查 MBS 中所有模块的最新构建，这些模块位于标签 'fedora-30-test-build' 的配置中，如果标签的继承数据中缺少任何构建的标签，该标签将被添加到继承中，同时将移除该模块的旧标签。

add-tag

从环境变量读取模块状态变更消息，然后根据标签配置文件添加模块的 koji 标签继承，如果模块构建状态为 'ready'，同时移除模块的旧标签。模块的状态变更消息由 MBS 生成。

参数

• --module-from-env (可选): 从 Ursa-Major 读取模块状态变更消息的环境变量，默认为 CI_MESSAGE

• --wait-regen-repo (optinal): 等待 regen-repo 任务完成，默认为 False

• --send-mail (可选): 向标签所有者发送邮件，默认为 False

示例

$ cat $CI_MESSAGE
{
  "state_reason": null,
  "component_builds": [
    108146,
    108145
  ],
  "name": "testmodule",
  "stream": "master",
  "time_submitted": "2018-10-26T16:59:06Z",
  "version": "20181026165847",
  "time_modified": "2018-10-26T16:59:27Z",
  "state_name": "ready",
  "scmurl": "https://src.fedoraproject.org/modules/testmodule.git?#3f262deef9d79160ea229142aeb51eedcc956929",
  "state": 5,
  "time_completed": "2018-10-26T16:59:15Z",
  "koji_tag": "module-testmodule-master-20181026165847-a5b0195c",
  "context": "a5b0195c",
  "owner": "foobar",
  "siblings": [],
  "id": 2321,
  "rebuild_strategy": "only-changed"
}

$ cat $PWD/ursa-major.json
{
    "fedora-30-test-build": {
        "modules": [
            {
                "name": "testmodule",
                "priority": 150,
                "stream": "master"
            }
        ],
        "owners": [
            "foobar@example.com"
        ]
    }
}

$ ursa-major add-tag --wait-regen-repo --send-mail

在这个例子中，Ursa-Major 从环境变量 CI_MESSAGE 读取模块状态变更消息，模块构建状态名称为“ready”，且模块位于标签配置文件中的“fedora-30-test-build”标签下。Ursa-Major 将将 koji 标签“module-testmodule-master-20181026165847-a5b0195c”添加到“fedora-30-test-build”的继承中，然后为“fedora-30-test-build”的继承中的构建标签重新生成仓库。

当标签被添加到标签继承时，Ursa-Major 还会提交继承数据中构建标签的 regen-repo 任务。如果指定的标签是构建标签，它将是 Ursa-Major 重新生成仓库的唯一构建标签。或者 Ursa-Major 将检查标签的继承数据，如果它达到每个继承路径中的第一个构建标签，它将返回该构建标签。并且它会在任何以 'module-' 开头的标签处停止。

例如，如果我们有以下标签继承数据（带有 '*' 标记的标签是构建标签）

示例 #1

my-example-tag
  └─product-foo-temp-override
     └─product-foo-override
        └─product-foo-build (*)
           ├─tmp-product-foo-build (*)
           └─alt-product-foo-build (*)

在这种情况下，为 'my-example-tag' 找到一个构建标签： product-foo-build。Ursa-Major 在 'product-foo-build' 处停止，因此没有检查 'tmp-product-foo-build' 和 'alt-product-foo-build'。

示例 #2

my-example-tag
  ├─module-345678-build
  ├─module-234567-build
  ├─module-123456-build
  │  └─product-foo-module-hotfix
  │     └─product-foo-module-hotfix-build (*)
  ├─tmp-product-foo-python-candidate
  │  └─tmp-product-foo-python-override
  │     └─tmp-product-foo-python-build (*)
  ├─product-foo-container-build (*)
  └─product-foo-temp-override
     └─product-foo-override
        └─product-foo-build (*)
           ├─tmp-product-foo-build (*)
           └─alt-product-foo-build (*)

在这种情况下，为 my-example-tag 找到 3 个构建标签： tmp-product-foo-python-build，product-foo-container-build 和 product-foo-build。 product-foo-module-hotfix-build 是构建标签，但 Ursa-Major 不将其计算在内，因为它在名为 'module-123456-build' 的标签处停止，该标签以 'module-' 开头。

如果使用“–send-mail”运行，Ursa-Major 将向标签所有者发送邮件，邮件配置可以在全局配置文件或用户配置文件中的“mail”部分进行配置。

0.5.1 (2024-07-09)

• 获取所有页面并添加 buildrequires 过滤器 (Yuming Zhu)

0.5.0 (2024-03-25)

• 每个标签的“tags_from”限制以限制模块构建的标签 (Yuming Zhu)

0.4.3 (2023-06-27)

• 使用 gssapi_login 替代 krb_login 进行 koji kerberos 身份验证 (Yuming Zhu)

0.4.2 (2021-03-10)

• 使用旧元组语法为旧 mock 版本的 mock.call.call_args (Yuming Zhu)

• 修复 unittests 以解决缺少 koji 配置文件的问题 (Yuming Zhu)

• 使用 libmodulemd v2 API (Yuming Zhu)

0.4.1 (2020-02-11)

• 从 add-module 和 remove-module 中移除更新 koji 继承的能力 (Qixiang Wan)

0.3.3 (2019-08-23)

• 添加新子命令 update-tag (Qixiang Wan)

0.3.2 (2019-06-26)

• 在检查现有模块构建标签时包括废弃的模块构建 (Qixiang Wan)

• 重构 get_modules (Qixiang Wan)

0.3.1 (2019-05-21)

• 不检查现有koji标签的requires/buildrequires（万琪翔）

• 更新现有继承而不是删除和添加（万琪翔）

0.2.2 (2019-03-26)

• 添加标签时，允许根据buildrequires进行过滤以找到标签继承中的koji_tags（齐翔龙）

0.2.1 (2019-03-20)

• 使setup_method/teardown_method与pytest的新版本兼容（齐翔龙）

• 将缺失的文件CHANGELOG.rst添加到sdist包中（齐翔龙）

0.2.0 (2019-03-20)

• 添加AddModuleHandler方法的测试（齐翔龙）

• 避免测试中嵌入过长的modulemd（齐翔龙）

• 根据审查意见进行修复（齐翔龙）

• 命令check-config支持根据buildrequires过滤模块（齐翔龙）

• 命令add-module现在支持buildrequires（齐翔龙）

• 命令remove-module支持根据buildrequires过滤模块（齐翔龙）

• 允许传递buildrequires给MBS.get_modules_with_requires（齐翔龙）

• 重新措辞remove-module帮助和–tag选项帮助文本（齐翔龙）

• 允许根据buildrequires进行过滤（齐翔龙）