Libseccomp: RFE:从 travis-ci.org 过渡到 travis-ci.com

创建于 2021-01-19  ·  10评论  ·  资料来源: seccomp/libseccomp

travis-ci.org 正在退役,并将在不久的将来消失。

按照此处的步骤将 libseccomp 转换到新的 travis-ci.com 站点。
https://docs.travis-ci.com/user/migrate/open-source-repository-migration

enhancement priorithigh

所有10条评论

我登录了 travis-ci.com,但他们仍处于测试阶段,因此我们还不能过渡。

呸! 他们绝对不会让这变得容易,是吗? ;)

由于过渡期限仍然是“模糊的”,温和地说,我将把它从 v2.5.2 里程碑中提取出来,让它浮动。 我们仍然需要在某个时候看看这个,但是在 Travis 采取行动之前,我们在这里无事可做。

我只是去验证 Travis 构建在一些推送后是否正常完成,我收到了这条消息:

自 2021 年 6 月 15 日起,travis-ci.org 上的建设已停止。 从现在开始请使用travis-ci.com。

...看起来我们需要解决这个问题,而且很快。

我对 Travis 的新商业模式有点怀疑。 看起来开源将保持免费(目前),但他们并没有让它变得容易。 我们可能需要定期向他们索取更多“信用”。
https://docs.travis-ci.com/user/billing-faq/#what -if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

呃,这很糟糕:/

我需要回忆一下你对 GH Actions 的了解; 它远非完美,但考虑到 Travis CI 的变化,它可能是更好的选择。

来吧……#299

好的,在#299 上刷新了我的记忆,我认为现在最好的选择是迁移到 GH Actions 并暂时坚持使用 x86_64 CI 构建。 这似乎是恢复 PR/branch 和代码覆盖率测试的最快途径,而且头疼问题最少。

缺乏其他拱门/ABI 令人不安,但实际上我们不会定期测试每个拱门/ABI(我们怎么能?)所以这不是世界末日。 如果它有帮助,虽然它不是“CI”,但我确实有一项夜间工作,它在一些私有基础设施上运行,在 aarch64 上构建和验证 libseccomp 主分支; 如果有什么东西坏了,我会在大约 24 小时内注意到它。 希望我们将来能找到更好的东西(我在这里有一些想法......)。

@drakenclimber 的想法?

我认为现在最好的选择是迁移到 GH Actions 并暂时坚持使用 x86_64 CI 构建。 这似乎是恢复 PR/branch 和代码覆盖率测试的最快途径,而且头疼问题最少。

听起来不错。 我可以拥有转换,因为我已经为 libcgroup 做了它。

我们在 libcgroup 中使用 Github Actions 已经有一段时间了,它运行良好。 这些工作很容易从 Travis 转移过来。

Github Actions 虚拟机没有提供我们在 libcgroup(一个完整的 cgroup v2 系统)中需要的功能,所以我最近在 Oracle Free Cloud 上创建了一个虚拟机,并通过 Github Actions 的自托管运行器将它连接起来。 它很容易设置,到目前为止运行良好。 我相信 GH Actions 自托管运行器逻辑支持 aarch64,所以如果我们有一个可以指向它的盒子,这可能是一种持续测试 ARM 的方法。

缺乏其他拱门/ABI 令人不安,但实际上我们不会定期测试每个拱门/ABI(我们怎么能?)所以这不是世界末日。

同意。 我喜欢当前测试的架构范围,因为它偶尔会发现奇怪的 32 位与 64 位以及大与小端问题。 在发布之前,我们应该(至少)跨其他架构运行测试。 也许我们可以招募过去的贡献者来帮助这里。

(我在这里有一些想法......)。

我都是耳朵。 我希望我能从 GH Actions 和 Travis 中取出最好的部分,并将它们放在一个 CI 中。

(我在这里有一些想法......)

对不起,我应该更清楚。 我的意思是我可能有一些关于支持 aarch64 的想法,而不是一般的 Travis/GH。

无论如何,感谢您在 PR #329 中的工作。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

pcmoore picture pcmoore  ·  23评论

srd424 picture srd424  ·  18评论

Xyene picture Xyene  ·  15评论

grubeli picture grubeli  ·  3评论

cgwalters picture cgwalters  ·  14评论