我们安装了Bitbucket Build Status Notifier插件，因此Bitbucket会在运行单元测试后跟踪哪些提交是绿色的。有没有办法利用此信息来确保选择正确的提交？
#1 楼
您没有提及要使用的脚本语言，因此，我将专门讨论对BitBucket API的HTTP请求：假设
一个其中包含三个提交的BitBucket存储库，第一个和最后一个都使构建失败，中间正在传递：
4768815❌
49d7110✅
42d357f ❌
获取提交列表
您可以通过调用以下API方法获取提交列表：
https://api.bitbucket.org/2.0/repositories/{{owner}}/{{repo_slug}}/commits owner：RichardSlater repo_slug：greencommitproofofconcept 响应看起来像这样：
{
"pagelen": 30,
"values": [
{
"hash": "4768815fdc27abf4be17096e7c460f7f68f5d39b",
"repository": { ... },
"links": {
...
"statuses": {
"href": "https://api.bitbucket.org/2.0/repositories/RichardSlater/greencommitproofofconcept/commit/4768815fdc27abf4be17096e7c460f7f68f5d39b/statuses"
}
},
"author": { ... },
"parents": [ ... ],
"date": "2017-04-10T11:38:18+00:00",
"message": "README.md edited online with Bitbucket",
"type": "commit"
},
{
"hash": "49d7110b98616358d16055960a4abdf2926b890d",
...
},
{
"hash": "42d357f1df7a7d7bcf1f10a9f3a5a40d85d5b11c",
...
}
]
}
如果解析JSON并遍历响应，则可以从以下状态中提取状态：
values[n].links.statuses.href
其中
n是索引，在上例中为0，1或2。如果您要从头开始构建它，它将采用以下格式。从commit中获取状态列表。
https://api.bitbucket.org/2.0/repositories/{{owner}}/{{repo_slug}}/commit/{{sha}}/statuses" owner：RichardSlater repo_slug：greencommitproofofconcept sha：4768815fdc27abf4be17096e7c460f7f68f5d39b />注意：这是一个Hypermedia API，这意味着URL可能会更改，因此我建议使用上一个响应中的链接，而不是尝试从头开始生成它们。
上述HTTP请求的响应将类似于：
{
"pagelen": 10,
"values": [
{
"key": "POC-01",
"name": "Build #1",
"repository": { ... },
"url": "http://devops.stackexchange.com/q/809/397",
"links": { ... },
"refname": null,
"state": "FAILED",
"created_on": "2017-04-10T13:04:28.261734+00:00",
"updated_on": "2017-04-10T13:04:28.261759+00:00",
"type": "build",
"description": "Changes by Richard Slater"
}
],
"page": 1,
"size": 1
}
从此响应中，您可以使用以下命令提取
state：values[n].state
再次其中
n是status-如果一次提交导致许多构建，则可能有很多。如果您关心的构建状态是
SUCCESSFUL，则您有答案，可以立即返回sha为t他犯了。循环从第一阶段开始的所有提交，如果您用尽了所有提交，请遵循对
next的调用中包含的link页面/commits。完整流程图
在较高的层次上，流程将如下所示：
别忘了这是一个Hypermedia API，因此只要有可能，您的代码就应该遵循该API中的链接而不是试图“猜测”它们。
#2 楼
在典型的持续交付/部署管道中，会发生以下情况：开发人员推送一个或多个提交，或者合并一个合并请求。
Jenkins自动生成并如果成功，詹金斯（Jenkins）会将部署包发布到Artefact信息库；如果失败什么也没有发布，并通知开发人员。
部署自动化使用Artefact资源库中的软件包并进行部署。
目标是避免从以下版本构建解决方案源代码两次，您一次构建一次，然后多次部署。您可以在Sonartype Nexus中实施批准以定义环境批准过程，即Dev→Test→UAT→Stage→Production。
...如果您已经阅读了前面的所有内容，但仍然想从源代码管理中获取最新的绿色版本，然后可以使用以下两种方法之一：
让Jenkins使用适当命名的标签来标记分支，即
master-green然后在您使用时代替master想要最新的绿色版本。使用BitBucket提交获取提交列表，并列出每个提交的提交/ {sha} /状态，以查找具有绿色状态的提交。我已经在另一个答案中扩展了此解决方案。
如果您想了解有关如何使用上述方法的具体细节，请随时发表后续问题。
评论
是的，它确实是我对SE的最长回答。
–Richard Slater
17年4月11日在8:51
即使您认为我完全想要它，我也很感谢您花时间来解释这一点。公认
– Alex
17年4月11日在12:51
只是迈出最初的几步，并不完全是疯狂的-在考虑CI / CD体系结构时，请记住我的其他答案。
–Richard Slater
17年4月11日在12:56