跳到主要内容

2、实践-构建命令写死版-不推荐

实践:构建命令写死版(不推荐)

image-20230921061155787

目录

[toc]

1、Jenkins共享库封装

💘 实践:Jenkins共享库封装(测试成功)-2022.5.20

🍀 问题背景 每个项目都需要创建一条流水线,很多代码都是重用的; 因此,需要使用Jenkins共享库/GitlabCI模板库 方式来解决!

1、创建共享库
2、配置共享库
3、创建作业核进行调试

1.创建共享库

  • 在jenkins上创建一个devops4的视图: 然后,接下来这个devops4下的所有项目统一由一个Jenkinsfile来管理:

  • 在gitlab创建一个叫做devops4-jenkinslib-service的项目: 创建它的目录结构: 把这个项目用wed ide打开: 创建src/org/devops目录: 创建Jenksfile文件: 具体目录结构如下:

  • 将代码下载步骤封装到共享库: org/devops/Checkout.groovy
// 下载代码
package org.devops

def GetCode(srcUrl, branchName){
checkout([$class: 'GitSCM',
branches: [[name: branchName]],
extensions: [],
userRemoteConfigs: [[credentialsId: '54df701e-d369-4f69-85c6-7209d45c283b',
url: srcUrl]]])
}

注意:这里的凭据是gitlab代码仓库里的gitlab账号信息,然后通过jenkins代码生成器生成的,最后是写在代码里的!

  • 将前后端等等各种工具的构建封装到共享库: org/devops/Build.groovy 注意: 本次构建工具都是用完整路径; 这里也可以采用map方式,本次就先使用简单点的方式测试: 实际,生产环境里,可能maven项目构建时可能存在很多不同的参数传递的:
package org.devops

def MavenBuild(){
sh "/usr/local/apache-maven-3.8.5/bin/mvn clean package"
}

def GradleBuild(){
sh "/usr/local/gradle-7.4.2/bin/gradle build"
}

def NpmBuild(){
sh "/usr/local/node-v16.15.0-linux-x64/bin/npm install && /usr/local/node-v16.15.0-linux-x64/bin/npm run build"
}

def YarnBuild(){
sh "yarn"
}

def CodeBuild(type){
switch(type){
case "maven":
MavenBuild()
break;
case "gradle":
GradleBuild()
break;
case "npm":
NpmBuild()
break;
case "yarn":
YarnBuild()
break;
default:
error "No such tools ... [maven/ant/gradle/npm/yarn/go]"
break
}
}
  • 将前后端等等各种工具的单元测试封装到共享库; org/devops/UnitTest.groovy 注意:以前我们把settings.xml文件放在代码库里,现在直接用构建机器上的就好,用全局那个。
package org.devops

//Maven
def MavenTest(){
sh "mvn test "
junit 'target/surefire-reports/*.xml'
}

//Gradle
def GradleTest(){
sh "gradle test"
junit 'build/test-results/test/*.xml'
}

//Ant
//def AntBuild(configPath="./build.xml"){
// sh "ant -f ${configPath}"
//}

//Golang
def GoTest(){
sh " go test"
}

//Npm
def NpmTest(){
sh "npm test"
}

//Yarn
def YarnTest(){
sh "yarn test "
}

//Main
def CodeTest(type){
switch(type){
case "maven":
MavenTest()
break;
case "gradle":
GradleTest()
break;
default:
println("No such tools ... [maven/ant/gradle/npm/yarn/go]")
break
}
}

此时库文件都创建好了,现在就剩编写Jenkinsfile了:

  • 这里需要注意下: 原来Jenkinsfile这里的参数不能写死在代码里,而是要拿出来放在jenkinsfile的ui那里,因为每个项目的srcUrl和branchName都不一样: 我们来找一个之前的项目,要特别配置下这个参数: 注意:这里的仓库地址就是自己写好的代码仓库地址及分支:

因为之前跑过流水线,所以这个job里已经存在配置了,没的话要自己添加下!

  • 我们找一个规律吧:

  • 进行如下配置:

最终Jenkinsfile完整代码如下:

@Library("mylib@main") _     //加载共享库
import org.devops.* // 导入库

def checkout = new Checkout() //New实例化
def build = new Build()
def unittest = new UnitTest()

env.buildType = "${JOB_NAME}".split("-")[1]

//流水线
pipeline {
agent { label "build" }

options {
skipDefaultCheckout true
}

stages{
stage("Checkout"){
steps{
script {
println("GetCode")
checkout.GetCode("${env.srcUrl}", "${env.branchName}")
}
}
}

stage("Build"){
steps{
script{
println("Build")
build.CodeBuild("${env.buildType}")

}
}
}

stage("UnitTest"){
steps{
script{
unittest.CodeTest("${env.buildType}")
}
}
}
}
}

进行提交一下:

2.配置共享库

复制一下这个仓库的链接: http://172.29.9.101/devops4/devops4-jenkinslib-service.git

进入Jenkins 设置, 定义共享库名称 mylib  默认的版本 main 。设置共享库的Git地址 [http://192.168.1.200/devops4/devops4-jenkinslib-service.git](http://192.168.1.200/devops02/jenkinslib.git) , 设置共享库的凭据。(如果没有提前创建好凭据,需要先去创建好然后再重新配置这个页面。)

全局配置那里,搜索下share: 注意:这里的仓库地址就是jenkins共享库的地址! 这里也是要加一个凭据的:凭据就是gitlab的账号!(gitlab共享库账号)

3.创建作业进行调试

  • 来到jenkins之前的那个maven项目,先测试一下maven: 填写如下相关信息: 这里的仓库地址就是jenkins共享库的地址,凭据就是gitlab账号:

  • 注意:一般要求job name要有一定的规范,如果不规范的话,就要在这里的jenkins ui里添加 一个类型或命令:(是后面那种情况)

  • 开始构建:

观察现象: 可以看到是构建是已经成功了,但是提示没有测试报告,我们来看下原因:

发现target目录真没有这个文件,这里直接把测试部分注销掉,然后再次提交,并再次构建,观察效果: 构建成功:

  • mavenok了,这里再测试下gradle: 按和上面maven一样的构建方法,这里观察下构建效果:

  • 注意:一般我们是把这个devops流水线搭建起来,给开发使用,开发改的最多的地方就是jenkins这里的master分支,及要执行的构建类型了。 每次构建成功后,这里的构建参数就不见了,需要我们再次配置下:

此时就出现了参数化构建选项了:

4.改进

  • 这里总还是很奇怪,需要改进下: 因为根据项目名称去命名基本是不可能的: 先来配置下jenkins的这个gradle项目,添加一个选项参数:

  • 再来修改下代码: 这里的代码直接不用了: 修改完,提交就好:

  • 此时,已gradle项目为例,进行构建: 可以看到,构建成功:

🍀 我们来看更加灵活的一种解决方法: 现在还有一个问题就是: 当你的构建参数比较多的时候,开发要执行的命令不规范,比如我再构建之前要执行一些其他的命令: 此时,我们该怎么办呢?

我们给开发一个shell命令,他自己去写: 你想怎么打包就怎么打包,你自己写:

但是,此时我们的平台就要有个命令的检查机制了: 例如:他来一个rm命令,虽然也没事儿,但可能也会把构建节点给搞坏了! 如果是容器也没啥问题:

这种方式就非常灵活了:

  • 本次gradle这里就改为gradle build

  • 再到gitlab上修改下代码:

比这个要灵活很多了:

如下环境: 平台提供了一个流水线的能力,去创建流水线是开发的同事去创建的,他会去选一些参数,例如构建类型,打包命令是什么,都是由开发同事去填的。填完之后会对应的在jenkins上生成这样一个job,最后devops平台在点构建的时候,它无非也是调用jenkins去构建的。

  • 可以看到gradel项目构建成功:

  • 最后,也把maven项目按如上方法改造下:

最终完整的Jenkinsfile文件:

@Library("mylib@main") _     //加载共享库
import org.devops.* // 导入库

def checkout = new Checkout() //New实例化
def build = new Build()
def unittest = new UnitTest()

//env.buildType = "${JOB_NAME}".split("-")[1]

//流水线
pipeline {
agent { label "build" }

options {
skipDefaultCheckout true
}

stages{
stage("Checkout"){
steps{
script {
println("GetCode")
checkout.GetCode("${env.srcUrl}", "${env.branchName}")
}
}
}

stage("Build"){
steps{
script{
println("Build")
//build.CodeBuild("${env.buildType}")
sh "${env.buildShell}"
}
}
}

/*stage("UnitTest"){
steps{
script{
unittest.CodeTest("${env.buildType}")
}
}
}*/
}
}

测试结束。😘

2、GitLab模板库

💘 实践:GitLab模板库(测试成功)-2022.5.20

注意后面为了通用,需要在项目中添加一个build.sh脚本, 里面存放构建相关的命令;

1.配置模板库

  • 在gitlab上创建一个叫做devops4-gitlablib-service的库:

jobs/CI.yaml

.pipelineInit:
tags:
- "${RUNNER_TAG}"
stage: .pre
variables:
GIT_CHECKOUT: "true" ##局部开启作业的代码下载
script:
- ls -l

.cibuild:
tags:
- "${RUNNER_TAG}"
stage: build
script:
- echo "${BUILD_SHELL}"
- ${BUILD_SHELL}
artifacts:
paths:
- ${ARTIFACT_PATH}

.citest:
tags:
- "${RUNNER_TAG}"
stage: test
script:
- echo "${TEST_SHELL}"
- ${TEST_SHELL}
artifacts:
reports:
junit: ${TEST_REPORTS}


gitlabci.yaml

include:
- project: 'devops4/devops4-gitlablib-service'
ref: main
file:
- '/jobs/CI.yaml'

workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "web"
when: always
- if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
when: never
- when: always

variables:
GIT_CHECKOUT: "false" ## 全局关闭作业代码下载
BUILD_SHELL: "sh -x build.sh" ## 构建命令
# TEST_SHELL: "mvn test " ## 测试命令
# ARTIFACT_PATH: "target/*jar" ## 制品路径
# TEST_REPORTS: "target/surefire-reports/TEST-*.xml" ##测试报告
RUNNER_TAG: "builder"

stages:
- build
- test

pipelineInit:
extends:
- .pipelineInit

cibuild:
extends:
- .cibuild


2.项目使用CI

  • 此时给一个runner打一个tag:

打开gitlab-ci.yml文件的raw格式: http://172.29.9.101/devops4/devops4-gitlablib-service/-/raw/main/.gitlab-ci.yml

  • 但是:注意,这个项目必须是公开的,因为它不支持认证访问!

  • 这里用maven项目测试:

  • 可以看到构建成功:

测试结束。😘

关于我

我的博客主旨:

  • 排版美观,语言精炼;
  • 文档即手册,步骤明细,拒绝埋坑,提供源码;
  • 本人实战文档都是亲测成功的,各位小伙伴在实际操作过程中如有什么疑问,可随时联系本人帮您解决问题,让我们一起进步!

🍀 微信二维码 x2675263825 (舍得), qq:2675263825。

image-20230107215114763

🍀 微信公众号 《云原生架构师实战》

image-20230107215126971

🍀 个人博客站点

http://47.97.48.237/ (即将上线域名:onedayxyy.cn)

image-20230917111843405

🍀 语雀

https://www.yuque.com/xyy-onlyone

image-20230912072007284

🍀 csdn https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

image-20230107215149885

🍀 知乎 https://www.zhihu.com/people/foryouone

image-20230107215203185

最后

好了,关于本次就到这里了,感谢大家阅读,最后祝大家生活快乐,每天都过的有意义哦,我们下期见!