-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add code coverage, Linux & macOS leg to Azure CI #264
Add code coverage, Linux & macOS leg to Azure CI #264
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: qmfrederik If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
awesome /LGTM |
why resharper code check was removed? |
The resharper check always failed when I ran this in my instance of VSTS; do I need any specific configuration to make that work? |
- task: DotNetCoreCLI@2 | ||
displayName: 'dotnet pack' | ||
inputs: | ||
command: pack | ||
packagesToPack: src/KubernetesClient/KubernetesClient.csproj | ||
packDirectory: '$(Build.ArtifactStagingDirectory)/nupkg' | ||
majorVersion: 1 | ||
minorVersion: 4 | ||
versioningScheme: byPrereleaseNumber |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why versioning was removed?
it is to replace git verison
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version numbers are embedded in the assemblies and NuGet packages you create. If you use build numbers which depend on external factors (such as the date and time the package was built or the CI job number), your build output (the binaries) will be different every time you build, even if you build from the same source.
This breaks reproducible builds. Having reproducible builds means I can clone this repository, build locally, get the SHA hash of the NuGet package it builds, and make sure it's the same which is uploaded on NuGet. It helps create trust.
The Kubernetes project is working towards reproducible builds - see kubernetes/kubernetes#70131, and I think it would be good if the same holds true for the .NET client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, I prefer to each build is an individual
.
The build machine cannot be exactly the same.
For example, when your update dotnet 1 to dotnet 2, the output/nuget of compiler might be changed even the source codes are totally the same.
The nuget is a snapshot and the release team is responsible for the official release
.
Maybe something like docker image could make the build reproducible
.
@brendandburns what is your opinion?
.azure-pipelines.yaml
Outdated
@@ -45,30 +28,66 @@ jobs: | |||
codeCoverageTool: 'cobertura' | |||
summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/coverage.cobertura.xml' | |||
|
|||
- task: alanwales.resharper-code-analysis.custom-build-task.ResharperCli@1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resharper?
install and try again |
New changes are detected. LGTM label has been removed. |
@qmfrederik this is great, let's restore the resharper check and then we can check in. Many thanks! |
Resharper is back, so we should be good. |
@qmfrederik this needs a rebase then it's good to go. |
@brendanburns This has been rebased and should be good to go |
I'm going to force push this in since we're hitting some sort of flake. |
This PR adds a macOS and Linux leg to the Azure CI pipeline script.
It reuses the CI scripts which are used on Travis.
Especially the Linux leg is of interest as it runs integration tests against a real Kubernetes cluster.
It also sets up code coverage reports which show line and branch coverage.