Jenkins持續集成學習-搭建jenkins問題彙總

時間  2019-11-09
標籤 jenkins 持續 集成 學習 搭建 問題 彙總 欄目 自動化構建 简体版
原文   原文鏈接

目錄html

Jenkins持續集成學習5-搭建jenkins問題彙總

目錄

Jenkins持續集成學習-Windows環境進行.Net開發1
Jenkins持續集成學習-Windows環境進行.Net開發2
Jenkins持續集成學習-Windows環境進行.Net開發3
Jenkins持續集成學習-Windows環境進行.Net開發4
Jenkins持續集成學習-搭建jenkins問題彙總git

前言

前面幾篇文字講解了在開發環境部署jenkins並經過SVN、Github、Gitlab進行持續集成。
因爲工做須要，須要在一個乾淨的服務器上部署jenkins用於測試環境的持續集成。因爲我本地的開發環境基本的環境及插件都已經存在了，所以部署的時候沒有碰到任何問題，可是在一個乾淨的開發環境部署的時候碰到了許多問題，且存在部分問題在網絡上找不到解決辦法，最終本身解決。github

問題列表

nuget還原包問題

nuget重置包的時候報錯，未經處理的異常: System.TypeLoadException: 未能從程序集「mscorlib, Version=4.0...
因爲不少項目仍然使用的是.net framework 3.5，所以仍然須要用msbuild 工具進行編譯，經過反編譯能夠看到我當前使用的4.9版本的nuget使用的是.net framework 4.6版本，而服務器上沒有安裝.net framework 4.6,安裝完成後解決。
20190226153328.pngjson

編譯問題

  1. 使用12.0版本的MSBuild編譯報錯。MSBUILD : error MSB1025: An internal failure occurred while running MSBuild.
    緣由：沒有安裝MSBuild編譯工具，我從我本地開發環境直接拷貝MSBuild工具C:\Program Files (x86)\MSBuild\12.0\Bin到服務器，調用MsBuild命令報錯Could not load file or assembly 'System.Threading.Tasks.Dataflow'...,最後經過安裝Microsoft Build Tools 2013成功編譯。windows

    同理編譯VS2015(MSBuild 14.0)項目須要安裝Microsoft Build Tools 2015。
    須要注意因爲VS2017安裝已經採用可選安裝，所以再也不提供Microsoft Build Tools 2017工具,須要經過VS2017安裝工具選擇MSBuild工具安裝
    20190225093152.png緩存

  2. 因爲VS2017支持以PackageReference方式引用nuget包。經過PackageReference的方式引用在Nuget包還原的時候會在obj目錄下自動生成Nuget包引用的配置文件project.assets.json、AsyncModule.NetMQ.2017.csproj.nuget.cache、AsyncModule.NetMQ.2017.csproj.nuget.g.props、AsyncModule.NetMQ.2017.csproj.nuget.g.targets。
    可是在本地使用Nuget Restore進行包還原後，在經過MSBuild編譯能夠經過，可是在Jenkins上一直通不過。服務器

  • 查看日誌檢查根本問題
    log 項目「D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj」(2)正在節點 1 上生成 「D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj」(2:2) (Build 個目標)。 15:23:53 C:\Program Files\dotnet\sdk\2.2.103\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): error NETSDK1064: 未找到版本爲 0.1.26 的包 AsyncIO。它可能已在 NuGet 還原後刪除。不然，NuGet 還原可能只是部分完成，這種狀況多是最大路徑長度限制所致使。 [D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]網絡

    因爲以前對於VS2017新的包引用方式不是很理解，且被其餘文章誤導認爲 project.assets.json只是存放包的依賴關係，認爲它是在VS中引用包時生成的，而實際該配置文件以及obj下其餘三個名爲*.csproj.nuget*的配置文件都是在Nuget包還原的時候自動建立的。框架

    因爲Jenkins一直報錯說找不到包(路徑能夠確定絕對沒有超長),所以經過對比直接nuget命令建立的配置文件和jenkins建立的配置文件有什麼差別。
    20190226162055.png
    左圖是在本地經過命令行進行包還原建立的配置文件，右圖是jenkins上調用命令行建立的配置文件。能夠發現兩個路徑是不同的。初步判斷編譯的時候會去配置的packageFolders查找包而因爲"C:\WINDOWS\system32\config\systemprofile\.nuget\packages\"路徑根本不存在，所以再去C:\Program Files\dotnet\sdk\2.2.103\Sdks下查找安裝的SDK包目錄，都找不到最終報錯。svn

  • 使用 dotnet build命令編譯

    在Package Restore一文中和NuGet is now fully integrated into MSBuild提到Nuget已經被集成到MSBuild了，所以在安裝過.net core sdk能夠直接經過dotnet build命令編譯自動重置nuget包。嘗試使用結果報錯

    D:\Jenkins\workspace\AsyncModule.NetMQ-V2>dotnet build AsyncModule.NetMQ\AsyncModule.NetMQ.2017.sln 
用於 .NET Core 的 Microsoft (R) 生成引擎版本 15.9.20+g88f5fadfbe
版權全部(C) Microsoft Corporation。保留全部權利。

正在還原 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj 的包...
正在還原 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj 的包...
正在還原 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\AsyncModule.NetMQ.Test.2017.csproj 的包...
正在生成 MSBuild 文件 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\obj\AsyncModule.NetMQ.2017.csproj.nuget.g.props。
正在生成 MSBuild 文件 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\obj\AsyncModule.NetMQ.Test.2017.csproj.nuget.g.props。
正在生成 MSBuild 文件 D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\obj\AsyncModule.NetMQ.Client.2017.csproj.nuget.g.props。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj 的還原在 223.01 ms 內完成。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\AsyncModule.NetMQ.Test.2017.csproj 的還原在 223.01 ms 內完成。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj 的還原在 223.01 ms 內完成。
C:\Program Files\dotnet\sdk\2.2.103\Microsoft.Common.CurrentVersion.targets(1179,5): error MSB3644: 未找到框架「.NETFramework,Version=v3.5」的引用程序集。若要解決此問題，請安裝此框架版 本的 SDK 或 Targeting Pack，或將應用程序的目標從新指向已裝有 SDK 或 Targeting Pack 的框架版本。請注意，將從全局程序集緩存(GAC)解析程序集，並將使用這些程序集替換引用程序集。所以，程序集 的目標可能未正確指向您所預期的框架。 [D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj]
C:\Program Files\dotnet\sdk\2.2.103\Microsoft.Common.CurrentVersion.targets(1179,5): error MSB3644: 未找到框架「.NETFramework,Version=v3.5」的引用程序集。若要解決此問題，請安裝此框架版 本的 SDK 或 Targeting Pack，或將應用程序的目標從新指向已裝有 SDK 或 Targeting Pack 的框架版本。請注意，將從全局程序集緩存(GAC)解析程序集，並將使用這些程序集替換引用程序集。所以，程序集 的目標可能未正確指向您所預期的框架。 [D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]
SocketSenderManager.cs(294,6): warning CS0162: 檢測到沒法訪問的代碼 [D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]
AsyncModule.NetMQ.2017 -> D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\bin\Debug\net40\AsyncModule.NetMQ.dll

    能夠發現編譯以前確實自動還原了包，可是最後編譯的時候報錯error MSB3644: 未找到框架「.NETFramework,Version=v3.5」的引用程序集。實際我本地開發環境是安裝過了.Net Framework 3.5,查找資料發現 dotnet build 不支持編譯.net 3.5 framework，能夠查看Support for .NET Framework 3.5和Cannot find reference assemblies for .NET 3.5 or lower using core msbuild。

  • jenkins環境變量問題。
    如今能夠基本肯定是包路徑問題，而爲何命令行直接編譯生成的配置文件和jenkins調用window命令生成的配置文件會不同呢，懷疑多是因爲jenkins的環境變量和windows的環境變量不同致使的。
    原來package.config的包管理方式會將包下載到程序目錄下，而PackageReference的包管理方式直接使用全局引用的方式，性能獲得了極大提高，在管理全局包、緩存和臨時文件夾一文提到關於global‑packages包路徑。

    global-packages 文件夾是 NuGet 安裝任何下載包的位置。 每一個包徹底展開到匹配包標識符和版本號的子文件夾。
    使用 PackageReference 格式的項目老是直接從該文件夾中使用包。 使用 packages.config 時，包將安裝到 global-packages 文件夾，而後複製到項目的 packages 文件夾。
    Windows：%userprofile%.nuget\packages
    Mac/Linux：~/.nuget/packages
    使用 NUGET_PACKAGES 重寫環境變量 globalPackagesFolder 或 repositoryPath 配置設置（分別在使用 PackageReference 和 packages.config 時）或 RestorePackagesPath MSBuild 屬性（僅限 MSBuild）。 環境變量優先於配置設置。

  • 設置環境變量添加NUGET_PACKAGES路徑
    20190226180258.png

    添加後必須重啓jenkins才能生效。再次編譯就成功了。

  • 設置Jenkins內部環境變量添加NUGET_PACKAGES
    既然是環境變量，那直接添加到jenkins內部便可,經過插件EnvInject Plugin能夠設置Jenkins內置的環境變量,在Build Environment勾選Inject environment variables to the build process設置環境變量，這樣設置不須要重啓，可是每一個job若是須要都須要額外設置環境變量。
    20190226182444.png

    17:14:06 [EnvInject] - Executing scripts and injecting environment variables after the SCM step.
17:14:06 [EnvInject] - Injecting as environment variables the properties content 
17:14:06 userprofile=C:\Users\Dm_ca
17:14:06 
17:14:06 [EnvInject] - Variables injected successfully.
17:14:06 [AsyncModule.NetMQ-V2] $ cmd /c call C:\WINDOWS\TEMP\jenkins3711651605143255297.bat
17:14:06 
17:14:06 D:\Jenkins\workspace\AsyncModule.NetMQ-V2>echo C:\Users\Dm_ca\.nuget\packages 
17:14:06 C:\Users\Dm_ca\.nuget\packages

    能夠看到環境變量已經設置成功,同時編譯也經過了。

  • 設置nuget全局包文件夾
    除了經過環境變量設置之外，還能夠在nuget.config配置中設置全局包文件夾。在nuget.config 引用文章中介紹了關於nuget配置獲取與設置的方法。經過在nuget.config配置文件中添加globalPackagesFolder設置全局的nuget的包文件路徑
    20190226174044.png
    再次構建就成功了。

SVN更新問題

jenkins檢出的代碼，若右鍵顯示svn 升級工做副本,緣由是Jenkins的SVN插件默認使用的是1.4版本的SVN客戶端，在系統管理-系統設置中找到SVN的配置修改成高版本便可。

參考文檔

  1. Package Restore
  2. NuGet is now fully integrated into MSBuild
  3. Support for .NET Framework 3.5
  4. Cannot find reference assemblies for .NET 3.5 or lower using core msbuild
  5. 管理全局包、緩存和臨時文件夾
  6. nuget.config 引用
  7. Jenkins：無效版本的SVN工做副本

本文地址：http://www.javashuo.com/article/p-pyqqwkbf-kp.html 做者博客：傑哥很忙 歡迎轉載，請在明顯位置給出出處及連接

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程