我的问题是是否有办法：
a）触发一个参数化的詹金斯作业
b）在触发作业时传递参数
#1 楼
这是我的方法：无需插件，只需从gitlab-ci触发Jenkinsapi。 首先，您需要在项目中拥有一个
.gitlab-ci.yml文件，该文件的基本结构如下：stages:
- my-jenkins-trigger
variables:
MY_VARIABLE: "EVERYTHING_IS_AWESOME"
my-jenkins-trigger-job:
stage: my-jenkins-trigger
script: curl -i -X POST --user JENKINS_USER:JENKINS_TOKEN JENKINS_JOB_URL/buildWithParameters?MY_JENK_PARAM=${MY_VARIABLE}
在上面，我还假设
您在URL
JENKINS_JOB_URL的某处有一个Jenkins作业此Jenkins作业具有一个名为
MY_VARIABLE的构建参数JENKINS_USER和JENKINS_TOKEN定义为[*] 那很简单吗？
是的，但是没有...
粗糙的结构。该脚本只会触发詹金斯的工作，而无需理会。您需要做更多的工作来监视作业并将其状态反馈到Gitlab-CI中，管理安全性，并可能从gitlab获取一些提交信息以注入到您的作业中。
为了进行适当的监视，我建议编写一个完整的触发器+监视器+返回值脚本[**]（使用任何可用的语言或您熟悉的语言）。
只需如上所述触发工作即可。
然后在
上运行
while循环（不要忘了将其放入sleep [***]） curl --silent --user JENKINS_USER:JENKINS_TOKEN JENKINS_JOB_URL/lastBuild/api/json | grep result\":null > /dev/null
直到此命令的结果不是
0。一旦Jenkins作业完成，您可能希望在Gitlab中获取作业的控制台。
curl -i -X POST --user JENKINS_USER:JENKINS_TOKEN JENKINS_JOB_URL/lastBuild/consoleText
最后一次可以在
curl上再次使用JENKINS_JOB_URL/lastBuild/api/json，但是这次您可以在grep，UNSTABLE或SUCCESS上使用它。讨论
通过遵循上述准则，您可以充分协调Jenkins的职位Gitlab-CI。我已经就如何以及何时执行此操作进行了长时间的讨论。
希望对您有所帮助。
[*]您的Gitlab项目设置> CI / CD>秘密物品
[**]当然，我的意思是用参数，函数，漂亮的变量名，有意义的日志来精心制作脚本...命名。
[***]我发现工作20秒的
FAILURE对我来说评论
您可以发布一个包含监视的完整示例吗？
– Jimkont
20年7月7日在13:07
这是一个while循环，我不知道您的功能。我没有故意写出完整的示例。我认为如果您能自己做，那就太好了！
–avi.elkharrat
20年7月7日在13:12
#2 楼
FWIW，您引用的触发器来自Gitlab存储库事件，而不是来自GitlabCI执行。自定义吗？）脚本作为GitlabCI执行的一部分被调用，该脚本通过适当的POST请求（其中包含所需的参数）远程激活为您的jenkins作业配置的参数化触发器插件。另请参阅https： //stackstackflow.com/questions/20359810/how-to-trigger-jenkins-builds-remotely-and-to-pass-parameters。
评论
我也是这么想的。。。现在的问题是如何使gitlab-ci知道通过api触发的工作的成功/失败；您认为这仅适用于源自gitlab repo事件的触发器；
– pkaramol
18年1月1日在10:04
嗯，那将完全管理jenkins作业，而不仅仅是触发它...也许在本地使用GitLab Runner运行自定义脚本，该脚本将触发jenkins作业并监视其状态，直到完成报告结果为止？
–丹·科尼莱斯库（Dan Cornilescu）
18年1月1日在13:48
#3 楼
如果要保持简单，请尝试使用普通的Webhook触发插件。https://plugins.jenkins.io/generic-webhook-trigger
您可以触发通过使用JSON正文或URL参数发送http POST进行构建。
解析JSON请求
def req = readJSON text: payload
现在，只要您具有部署功能，就可以在管道中使用它。
deploy(req.environment, req.branch)
我必须同意@Tensibai。表面上的两个CI / CD系统似乎过于复杂。如果可能，您可能要考虑坚持使用。
评论
您要传递什么参数？什么动作会导致触发？在某个时候，我希望gitlab-ci作业能够调用jenkins在业务流程服务器（Rancher）上执行部署。参数将是环境的名称以及将从中执行代码检出的仓库分支（以便构建要部署的映像）
为什么要链接两个CI系统？我不太了解它，因为gitlab-ci可以直接触发在k8s集群上的部署，因此在中间添加jenkins听起来比帮助情况要复杂得多。