更新- 2020年3月9日

即将到来的变化

在…上2020年3月9日,我将开始使管道对所有免费的项目。管道包含在项目的触发器之后CircleCI运行的所有工作流(以及这些工作流中的作业)。管道可以由一个拉请求、一个提交甚至一个API调用触发。

为了减轻任何不可预见的问题,我们建议你使管道在3月9日之前高级设置项目设置

请注意

  • 使管道需要使用2.1配置语法。2.0配置在启用管道时工作。
  • 没有已知的问题向管道转移的项目数量。

使用管道的好处

  • 新CircleCI接口
  • V2 API
  • 访问版本2.1 config,它提供:
  • 现在,您可以在高级设置中启用自动取消,以在非默认分支上触发新构建时中止工作流。

如果您有任何问题或担忧,请随时在这里发布。

构建快乐!

3喜欢

我的项目已经使用管道一段时间了,效果不错,所以:听起来不错!

有一个问题:我刚开始看到一堆管道显示在UI中,只有字符串“没有要为此管道执行的工作流”。

这是怎么回事?

@avi谢谢你的提高。只有当管道没有工作流时才会显示。如果您的配置可能针对被推送或标签推送的不同分支,则会发生这种情况。这两个有可能是源头吗?

@Kate_Catlin谢谢您的快速回复!这是有意义的;我的项目有一个工作,它自动创建一个预发布实体,在GitHub repo中有一个相应的标签(在Git的意义上),如果所有其他工作都成功的话。这相当于推入一个新标签。

然而:

  • 我的工作流程已经有一段时间没有明显改变了。为什么这些无操作管道最近才开始出现在列表中?
  • 如果这是您最近故意做的更改,那么这些管道没有说明为什么要创建它们,为什么没有工作要执行,这就有点令人不安了。如果/当这些管道将显示在列表中,我建议您增强它们,使这些信息可用和可访问。
  • 我如何隐藏或抑制这些管道向前?
1像

非常具体的反馈,谢谢@avi

它们总是显示,之前只是空白行。甚至更少的信息正在显示什么!也许你以前注意过这些空白行?

我们正在制作一张卡片来解决这个问题,因为你昨天的帖子,所以是的,我们在上面: slight_smile:如果你在设计这个,哪些信息是最有帮助的?

这是一个有趣的想法,在等待进一步的数据点时,我们可能无法在我们的路线图上确定优先级。

1像

我的荣幸!

杰出的

在我的脑海中,我想我希望能够清楚、快速、一目了然(即扫描时)看到是什么事件促成了管道的创建(即推送了标签)。我希望能够找到/了解为什么该事件没有触发任何工作流运行。换句话说,我想我应该能够点击它,将其展开一点,然后深入查看:如果它是一个标记或分支,那么它的名称和sha是什么。也许可以通过某种方式理解(即使只是文档链接)为什么该事件没有触发工作流。i、 如果它是一个与工作流配置中的某个模式不匹配的分支,那么最好显示它。

我希望这能讲得通,这是我一时想不起来的。我相信你已经想出了一个更连贯的方法眨眼:

有道理,不用担心!

CLI现在是否能够运行2.1配置(本地),还是我们仍然停留在2.0?

启用管道——这是一个潜在的破坏性行为吗?

也就是说,现有的配置是否会中断?还是向后兼容?

我一直在寻找有关这将会产生的影响的信息,但一直没有找到。

非常感谢

马特

2喜欢

@Kate_Catlin@KunalJain如果能得到回复就好了。

1像

嗨,马特,

启用管道——这是一个潜在的破坏性行为吗?
也就是说,现有的配置是否会中断?还是向后兼容?

启用管道应该不会破坏您的项目。你可以尝试管道通过添加管道:真在您的配置中,在为您的项目启用它之前。

如果你有任何问题,请随时打开这个线程。

你好,Blair -我们正积极致力于启用配置来构建作为2.1的一部分。一旦PR被合并,我将ping这个线程。非常感谢您的耐心等待。

谢谢@KunalJain

顺便说一下,我在模式中发现了一个重大变化:在版本2中工作良好的作业名称在版本2.1中产生了错误。

我最终找到了冒号()。当我用下划线(_),错误消失了。

这是一个重大的更改,所以如果您遵循semver,新版本应该确实有一个主要的版本更改。

1像

@KunalJain你知道这个突然的变化吗?

嗨,马特,

我很抱歉听到你从配置版本2升级到2.1有问题。我是实现2.1配置的团队成员,我想分享一些关于我们所做的破坏性改变的背景。

需要注意的一点是,配置版本2.1是opt-in,管道不需要它。

经过一系列迭代之后,我们得到了现在的“配置版本2”,我们自己使用2.0配置的早期版本构建了2.0平台,随后与一些合作伙伴进行了封闭测试。我们一直在配置格式上迭代。当我们最终调用CircleCI 2.0“发布”时,配置文件格式在内部有相当数量的向后兼容性垫片,从这里我们已经迭代了配置模式。这导致我们有一些非常糟糕的错误消息无效配置,因为我们有一些手写的模式检查,允许许多有问题的yaml构建。2.0版本迭代,我们经过一段时间,出现越来越多的客户在一个封闭的β,β和开放,等等,所以我们从来没有一个单一的“释放”,我们将能够定义“完成”配置模式,打破2.0客户采取了早期的构建)。

当我们开始这个项目在配置中添加的特性,我们添加了版本2.1(命令、参数、球体等),我们发现,我们不能将这些新特性添加到配置2.0的方式是向后兼容的前提下设计,或在某种程度上产生有用的错误信息。我们决定做一个彻底的突破,将配置版本提升到2.1。

配置版本2.1在接受什么方面比2.0严格得多,特别是在不期望的附加键方面。特别是,在配置2.0中,您可以在YAML文档的几乎任何地方添加额外的键,而我们的解析器将忽略它们。这将导致输入错误被悄悄地忽略。当我们查看数据时,我们发现resource_class是最常拼错的钥匙。这里的陷阱是,如果你添加资源类:大型到你的配置文件,但你拼错了资源,我们的配置验证2.0将忽略这个键,您的作业将在媒介资源类上运行。

我们加强的另一个方面是我们允许的名称——我们限制了配置文件中一串字段的字符集和长度。在这里影响你的是工作名称。我们对内容或orb添加了很多限制,因为它们存储在注册表中,通过API传递,在命令行工具中处理,等等。因为作业可以包含在orb中,所以我们限制了一个作业可以被调用的内容,这个限制是全局的,并且影响配置文件中的所有作业。

这就是背景: slight_smile:

在您的例子中,您知道产生的错误消息是什么吗?我增加了一份工作在我逃跑的时候circleci配置验证在命令行工具中,我得到如下信息:

/dev/circleci/circle $ circleci config validate: Error IN config FILE: [#/jobs/job-with-a-:- IN -name] string [job-with-a-:- IN -name] does not match pattern ^[[A-Za-z][A-Za-z\s\d_-]*$

你收到类似的错误信息了吗?将正则表达式作为错误消息的一部分返回给用户并不是我们在这里传达问题的最清晰的方式。你有什么想法,我们可以显示什么错误信息,让你明白问题是什么?

谢谢

马克

1像

@marc

感谢您的详细回复,并对我迟来的回复表示歉意。

我试图强调的是,一个破坏的更改应该反映在版本号中- config在版本2中起作用,在版本2.1中起作用,所以在semver之后,新的版本应该是3。

或者配置版本的主要部分与整个circlici版本绑定?

回答你的问题……

你收到类似的错误信息了吗?

是的,这就像我收到的错误信息。它是通过更换具有_

你有什么想法,我们可以显示什么错误信息,让你明白问题是什么?

如果显示错误发生的行号将更有用—就目前情况而言,我不知道哪个作业有无效的名称。

的确,我可以(也确实)查看正则表达式,但这只是解决方案的一部分:我需要能够直接找到错误的根源。

再次感谢您的回复。

亲切的问候

马特

这个前面提到的管道特性现在已经完成。看到公告发布为更多的细节。

1像