I'm trying to build several solutions with Github Actions. I'm using a matrix strategy since I need to build for Release and Debug, in x64 and x86, however, I can't find how to use wildcards to build multiple solutions. I currently have this:
jobs:
samples-build-VS-2019:
runs-on: windows-2019
strategy:
matrix:
configuration: [Release, Debug]
platform: [x86, x64]
steps:
- uses: actions/checkout#v2
- name: Setup MSBuild.exe
uses: microsoft/setup-msbuild#v1.0.3
- name: Use NuGet 5.2.0
uses: nuget/setup-nuget#v1
- name: Restore nuget packages for all solutions
run: msbuild 'Samples/**/*.sln' /p:configuration=${{ matrix.configuration }} /p:platform=${{ matrix.platform }} /t:restore
- name: Build all Sample solutions
run: msbuild 'Samples/**/*.sln' /p:configuration=${{ matrix.configuration }} /p:platform=${{ matrix.platform }}
Unfortunately, that gives me a "MSBUILD : error MSB1009: Project file does not exist." error.
Is it even possible to do this? I need to do it like that because I need the CI to run on Pull requests that add new solutions/projects, as well as existing solutions.
Related
I recently connected my GitHub solution to my Azure AppService and it automatically created a yml build and deploy file which is great, thanks Microsoft. The issue is I have 4 projects in my solution but only want the Api deployed to the App service. How to I specify that?
build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v2
- name: Set up .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: '7.x'
include-prerelease: true
- name: Build with dotnet
run: dotnet build --configuration Release
- name: dotnet publish
run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp
- name: Upload artifact for deployment job
uses: actions/upload-artifact#v2
with:
name: .net-app
path: ${{env.DOTNET_ROOT}}/myapp
deploy:
runs-on: windows-latest
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
steps:
- name: Download artifact from build job
uses: actions/download-artifact#v2
with:
name: .net-app
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy#v2
with:
app-name: 'popupshop'
slot-name: 'Production'
publish-profile: ${{ secrets.somesecret}}
package: .
After much trial and error:
run: dotnet build ProjectFolder/Project.csproj --configuration Release
...
run: dotnet publish ProjectFolder/Project.csproj -c Release -o ${{env.DOTNET_ROOT}}/myapp
I'm new to github actions (comming from gitlab-ci) I'm trying to run a integration test with testcontainers in the pipeline and I'm stucked. Here is my current definition.
name: Run Gradle
on: push
jobs:
gradle:
strategy:
matrix:
os: [ ubuntu-18.04 ]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout#v1
- uses: actions/setup-java#v1
with:
java-version: 11
- uses: eskatos/gradle-command-action#v1
with:
build-root-directory: backend
wrapper-directory: backend
arguments: check assemble
How can I ensure that the docker deamon for testcontainers project is available during my run?
You can check the installed packages/software for each GitHub Actions Runner as part of the virtual-environment GitHub repository.
For ubuntu-18.04 you can find the list here. Docker and Docker Compose are already installed on the runner and you can use them without any additional configuration for Testcontainers.
I'm using GitHub Actions for a lot of projects that make heavy use of Testcontainers without any problems.
I have created SPFX library module in which there is code to be shared with multiple webparts similar to the one here. I used npm link <lib name> command to link it. It works pretty well in the local environment as well as when I deploy it manually in SharePoint online app catalog. But if I deploy it using Azure Pipelines (YAML script) it always throws and error for library not found.
I have made it sure that the library is built first and then other webparts are built in pipeline (by introducting stages) but still it doesn't find the library. Is there a way to run npm link as a pipeline task?
If the library is first built in a different stage or job, the library will not be located in the same agent machine with the other webparts.
Let's say the library is built in Stage A and the other webparts are built in Stage B. As workaround, you will need to publish the library as artifacts to azure devops server using Publish Build Artifacts task in stage A. And then download the library to the agent which builds the other webparts in Stage B using Download Build Artifacts task.
For below example:
The library is built in stage A and published to azure devops server as artifacts named library.
In Stage B, the library artifacts is downloaded from azure devops server to folder $(Build.ArtifactStagingDirectory). Then you can refer to the library by path $(Build.ArtifactStagingDirectory)/library for the following tasks in Stage B.
If multiple webparts are built in different jobs in Stage B, each job in Stage B will need to download the library artifacts, for different jobs run on different agent virtual machines.
stages:
- stage: A
jobs:
- job: Library
pool:
vmImage: "windows-latest"
steps:
...
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: {path to the library}
ArtifactName: library
- stage: B
dependsOn: A
jobs:
- job: WebParts1
pool:
vmImage: "windows-latest"
steps:
- task: DownloadBuildArtifacts#0
inputs:
downloadPath: $(Build.ArtifactStagingDirectory)
buildType: current
artifactName: library
...
- job: WebParts2
pool:
vmImage: "windows-latest"
steps:
- task: DownloadBuildArtifacts#0
inputs:
downloadPath: $(Build.ArtifactStagingDirectory)
buildType: current
artifactName: library
...
After trying the solutions posted above it still didn't work so I published it as NPM package using npm publish command. This solved the problem.
We can also use this command in YAML to automatically publish the package everytime we build but that was not required in my case so I didn't use it.
We are using azure dev ops for CICD and validating PR's.
Yesterday I decided to start making yaml files for validation builds.
I created the pipeline. I set the branch policy for 'development' fine and the validation build ran okay.
However, something I see is that each time ANY branch gets a change to the files of the directory I've set the validation build for a build triggers.
So, let's say I've made a yaml pipeline(CI only) for project Main(src/Main) and i've set a branch policy on branch 'development' to trigger a validation build whenever there is a change to that Main folder(src/Main/*) with the Main.sln inside and it has been PR's from branch(i.e. feature/Main/FirstPR). This works, but then if i merge 'development' into any branch which has not had the change to the main directory it will trigger that build. No other branch policy includes validation for Main apart from development even if it has not been PR-ed, but simply pushed to.
Here is an example of the yaml file. Any feedback would be appreciated.
# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
pool:
vmImage: 'windows-2019'
demands:
- msbuild
- visualstudio
- vstest
variables:
solution: 'src/Main/Main.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
inputs:
versionSpec: '5.0.0'
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '$(solution)'
feedsToUse: 'select'
vstsFeed: '5aaa76ac-3bqa-4567-usd9-btdse1c4c66a'
restoreDirectory: '../../packages'
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
Set;
# A pipeline with no trigger
trigger: none
On your validation build pipeline. This will stop the build being run regardless of which branch / paths have been pushed.
The validation build pipeline will still respect the branch policies you've setup for PRs.
You can then have something like;
paths:
include:
- 'src/ProjectA/*'
branches:
include:
- development
For your CI build pipelines which will trigger when there's a successful PR that affects ProjectA.
I have setup CI for a .NET Core solution using GitHub Actions. When code is pushed to the master branche, the solution is build, the unit tests are run and code analysis is run with SonarCloud.
The code analysis step is actually performed by sonarcloud-github-action.
The quality gate in SonarCloud does not pass because the coverage percentage is 0.0% (for both new as existing code). I'm generating code coverage reports using Coverlet. The coverage.opencover.xml file is succesfully generated after test execution for each unit test project.
In the sonar-project.properties file I'm referencing these files as follows:
sonar.cs.opencover.reportsPaths=**\coverage.opencover.xml
But apparently the code coverage reports are recognized but not processed by the SonarCloud scanner.
In the log of my GitHub Actions workflow, I do see these warnings:
INFO: Parsing the OpenCover report <path>/coverage.opencover.xml
INFO: Adding this code coverage report to the cache for later reuse: <path>/coverage.opencover.xml
...
WARN: Missing blame information for the following files:
WARN: * <path>/coverage.opencover.xml
WARN: This may lead to missing/broken features in SonarQube
In trying to solve the 'Missing blame information' warning, I added the coverage files to the exclusions in my SonarCloud project: **/coverage.opencover.xml but that didn't solve the issue. The warning still appears and code coverage is still 0.0%.
Any hints to get this going?
[edit]:
My workflow in GitHub Actions looks like this:
name: .NET Core
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Setup .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: 2.2.108
- name: Build with dotnet
run: dotnet build src/<solution>.sln --configuration Release
- name: Unit Tests
run: dotnet test src/<solution>.sln /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
- name: SonarCloud Scan
uses: sonarsource/sonarcloud-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
`
I had a similar problem getting the coverage of a Typescript project to work. Without your sonar logs I just can guess but the problem was that the paths inside the lcov.info where absolute path from github something like SF:/home/runner/work/YoutRepoName.. and Sonar was starting a Docker container and set the workdir to /github/workdir and therefore could not locate the files from the lcov.info.
Check your logs if you find something like
2019-11-28T15:36:34.9243068Z WARN: Could not resolve 2 file paths in [/github/workspace/test/unit/coverage/lcov.info], first unresolved path: /home/runner/work/jobreporter/jobreporter/dispatcher/index.ts
2019-11-28T15:36:34.9243445Z INFO: Sensor SonarJS Coverage [javascript] (done) | time=8ms
So for the time being i had to replace all folder namens in the locv.info with /github/workdir.
In my case i used
- name: 'Run npm lint and test'
shell: bash
run: |
pushd .
npm ci
npm run lint:ci
npm run test --if-present
sed -i 's+/home/runner/work/jobreporter/jobreporter+/github/workspace+g' test/unit/coverage/lcov.info
sed -i 's+/home/runner/work/jobreporter/jobreporter+/github/workspace+g' eslint-report.json
After that the coverage was reported correctly.
Maybe that helps
Regards Mathias
I had the same problem with a Node build, where the paths in the lcov.info are not the same as the one in the Github Action docker container.
To work around it, I do my builds not by setting up Node directly in the worker, but by using a Docker Action, so that my paths stay the same in all Actions. If you dig in the logs, you can see precisely how the docker actions are run, and the available environment.
For reference, my actions look like this
- name: 'yarn install'
uses: docker://node:10.16.3-buster
with:
args: yarn install
env:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
CI: true
The downside is that my builds are a bit slower, but all my actions are run in Docker, which I find cleaner.
To get past this error you need to run your tests with the --blame parameter.
Here is my GitHub action for building and pushing to SonarCloud.
name: Build and run tests
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
# Disabling shallow clone is recommended for improving relevancy of reporting for sonarcloud
fetch-depth: 0
- name: Setup .Net SDK (v5.0)
uses: actions/setup-dotnet#v1
with:
dotnet-version: '5.0.100'
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Test
run: dotnet test --blame --no-restore --verbosity normal /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput=opencover.xml
- name: SonarCloud Scan
uses: sonarsource/sonarcloud-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}