使用jenkins for Linux构建网络核心项目

最新推荐文章于 2024-09-27 10:11:28 发布

weixin_26755331

最新推荐文章于 2024-09-27 10:11:28 发布

阅读量72

点赞数

文章标签： python java 人工智能区块链大数据

原文链接：https://medium.com/@babaknia/build-net-core-projects-with-jenkins-for-linux-63a16f2a3414

版权

As a part of our CI/CD pipeline we are using Jenkins. For short, it gets files from repositories, runs tests, prepares front-end files and builds published version of our projects and pushes the result in another repositories.

作为CI / CD管道的一部分，我们使用Jenkins 。简而言之，它从存储库中获取文件，运行测试，准备前端文件并构建我们项目的发布版本，并将结果推送到另一个存储库中。

I know that it may not a perfect solution but it works well for us. I’m sharing this story to hear your opinion, too.

我知道这可能不是完美的解决方案，但对我们来说效果很好。我也在分享这个故事，以听听您的意见。

Our Jenkins server is on a cloud service and we turned it on when we need it.

我们的Jenkins服务器在云服务上，我们在需要时将其打开。

This is an empty Groovy template:

这是一个空的Groovy模板：

pipeline {
 environment {
  variable1 = value
 }agent { label "master" }stages {
  stage() { }
 }post {
  always { }
 }
}

We have two source repositories, Source and Docs. One contains all codes and projects which almost all member of the team has access to it. The other one contains sensitive data to replace on the build process. Only a few member has permission to view or edit it.

我们有两个源存储库，即“源”和“文档”。其中一个包含几乎所有团队成员都可以访问的所有代码和项目。另一个包含在构建过程中要替换的敏感数据。只有少数成员有权查看或编辑它。

Here is the sample of variables:

这是变量的示例：

environment {
 CREDENTIALS_ID = "The-Key-Name" GIT_BRANCH = "master"
 GIT_DOCS = "git@.../nihonto-docs.git"
 GIT_SOURCE = "git@.../nihonto-genesis.git"
 GIT_TARGET = "git@.../nihonto-publish-production.git" DOCS_PATH_Type = "Production"
 REPO_PATH = "repo"
 SOURCE_PATH = "source"
 TARGET_PATH = "target" STORE_PATH = "$SOURCE_PATH/dev/app/Nihonto/Web/Nihonto.Web.Store" PUBLISH_PATH = "$WORKSPACE/$TARGET_PATH/published"
 STORE_PUBLISH_PATH = "$PUBLISH_PATH/Nihonto.Web.Store"
}

It is very easy to copy this script and change it for a nightly build by only change the `GIT_BRANCH` value to `develop`. Don’t forget to define variable for everything. We have three copies of this script for our nightly build, staging and production and changed their variables respectably.

这是很容易复制这个脚本，并通过只改变它每晚构建改变``GIT_BRANCH值`` 发展。不要忘记为所有内容定义变量。我们有此脚本的三个副本用于我们的每晚构建，暂存和生产，并分别更改了它们的变量。

Now stages:

现在阶段：

If you need to clean any path:

如果您需要清理任何路径：

stage("Clean") {
 steps {
  dir (SOURCE_PATH) {
   deleteDir()
  }
 }
}

This is how to get codes from repositories:

这是从存储库获取代码的方法：

stage("Checkout") {
 steps {
  dir (REPO_PATH) {
   git branch: GIT_BRANCH, credentialsId: CREDENTIALS_ID, url: GIT_SOURCE
   sh 'cp -Rp ../$REPO_PATH ../$SOURCE_PATH'
  }
 }
}

Note that we clean `SOURCE_PATH` and then copy files from `REPO_PATH` in to that path. In this way we are sure that Git only gets new changes and not all the repository (just to make the pipeline a little faster when you do not have a good Internet connection) and no remaining from the previous build.

注意我们先清理` SOURCE_PATH` ，然后将文件从` REPO_PATH`复制到该路径。这样，我们可以确保Git仅获得新更改，而不是所有存储库(只是为了在没有良好Internet连接时使管道更快一点)，并且不会从以前的构建中获得任何剩余。

Now update the source with data from docs:

现在使用来自文档的数据更新源：

stage("Set Docs") {
 steps {
  dir (STORE_PATH) {
   sh 'cp -rfv $WORKSPACE/$DOCS_PATH/Favicon/$DOCS_PATH_Type/Nihonto.Web.Store/* ./wwwroot/'
   sh 'cp -rfv $WORKSPACE/$DOCS_PATH/Setting/$DOCS_PATH_Type/Nihonto.Web.Store/* ./'
   sh 'sed -i -- "s|__JS_VERSION__|$BUILD_NUMBER|gI" ./appsettings.json'
  }
 }
}

We have different icon sets to reduce confusion when have both development and production tabs open in our browsers.You may note that after copying the `appsettings.json` we do some modification, too. For example, we append the build number to our JavaScript files to make sure users have the latest version of those files.

我们有不同的图标集来减少浏览器中同时打开开发和生产选项卡时的混乱。您可能会注意到，在复制` appsettings.json`之后，我们也做了一些修改。例如，我们将内部版本号附加到我们JavaScript文件中，以确保用户具有这些文件的最新版本。

Let’s run some unit-tests:

让我们运行一些单元测试：

stage("Test") {
 steps {
  dir (TEST_PATH) {
   sh 'dotnet test --logger "trx;LogFileName=nihonto-test.trx" --configuration Test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover'
  }
 }
}

Wonder what are all those arguments, here is a nice plugin to draw graph from your test results: https://wiki.jenkins.io/display/JENKINS/MSTest+Plugin

想知道所有这些参数是什么，这是一个不错的插件，可从您的测试结果绘制图形： https : //wiki.jenkins.io/display/JENKINS/MSTest+Plugin

One of the nice thing about Jenkins is that you can use other tools, too. Here we are running Grunt to compile Sass files and minify other front-end scripts:

Jenkins的优点之一就是您也可以使用其他工具。在这里，我们运行Grunt来编译Sass文件并最小化其他前端脚本：

stage("Script CSS Build") {
 steps {
  dir (STORE_PATH) {
   sh 'npm install'
   sh 'grunt build-linux'
   sh 'rm -rf /wwwroot/js-dev'
  }
 }
}

Now it’s time to publish it:

现在是时候发布它了：

stage("Publish") {
 steps {
  dir (STORE_PATH) {
   sh 'dotnet publish --configuration Release --output $STORE_PUBLISH_PATH'
  }
 }
}
stage("Push") {
 steps {
  dir (TARGET_PATH) {
   sh 'git add .'
   sh 'git commit -am "Jenkins $JOB_NAME $BUILD_NUMBER"'
   sshagent(credentials: [CREDENTIALS_ID]) {
    sh 'git push origin master'
   }
  }
 }
}
stage("Packing") {
 steps {
  dir (PUBLISH_PATH) {
   sh 'mkdir -p $WORKSPACE/out'
   sh 'tar -zcf store.tar.gz $STORE_PUBLISH_PATH/ && mv store.tar.gz $WORKSPACE/out'
  }
 }
}

We push the result to other repository and archive it just to know when we had a build and what was in it. Note that for nightly build and staging we ignore this part.Compressed packages are ready to deliver to the production servers.

我们将结果推送到其他存储库并将其存档，以了解何时拥有构建以及其中包含什么。请注意，对于每晚的构建和暂存，我们将忽略此部分。压缩包已准备好交付给生产服务器。

After all those stages we still need to do a little work:

在所有这些阶段之后，我们仍然需要做一些工作：

post {
 always {
  step([$class: 'MSTestPublisher', testResultsFile:"$TEST_PATH/TestResults/nihonto-test.trx", failOnError: true, keepLongStdio: true])
 }
}