Issues creating a CD based release on Github (WPF .NET 5.0) - continuous-integration

I'm trying to put together a CI / CD pipeline for GitHub and strugglign with attaching my build artifact to the release. Here's my ci.yml
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch:
jobs:
Build:
runs-on: windows-latest
env:
BuildPath: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
steps:
- uses: actions/checkout#v2
- name: Setup .NET SDK
uses: actions/setup-dotnet#v1.8.1
with:
dotnet-version: 5.0.x
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Upload a Build Artifact
uses: actions/upload-artifact#v2.2.4
with:
name: thingy
path: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
retention-days: 1
That runs well and I get a release artifact:
I was under the impression I'd be able to download that existing artifact but I couldn't get my head around why actions/download-artifact isn't downloading anything. So I found another article and in their cd step they were re-building, so I figured that in doing that at least I'd have a fresh build in the cd workflow to pull from. So I create a release triggered on tag push events. I can't use most zip utilities becuase they don't run on windows. I have to user windows-latest as the target framework for WPF desktop applications has to be net5.0-windows and using ubuntu-latest it fails. I tried papeloto/action-zip#v1 and in one case I managed to get a zip file which then attached to the release successfully but was only 22 bytes, so empty once I downloaded it. Here's my cd.yml:
name: CD
on:
push:
tags:
- '*'
jobs:
Release:
runs-on: windows-latest
env:
BuildPath: ${{ github.workspace }}\BuildTesting\bin\Release\net5.0-windows
ZipName: TheThing.zip
steps:
# Build the solution
- uses: actions/checkout#v2
- name: Setup .NET SDK
uses: actions/setup-dotnet#v1.8.1
with:
dotnet-version: 5.0.x
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Zip the release
uses: << What should I use to zip ${{ env.BuildPath }} ? >>
# Create a Release on the GitHub project
- name: Create release
id: create_release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
with:
tag_name: ${{ github.ref }}
release_name: ${{ github.ref }}
draft: false
prerelease: false
# Upload the Build Artifact to the Release
- name: Update release asset
id: upload-release-asset
uses: actions/upload-release-asset#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }} # This pulls from the CREATE RELEASE step above, referencing it's ID to get its outputs object, which include a `upload_url`. See this blog post for more info: https://jasonet.co/posts/new-features-of-github-actions/#passing-data-to-future-steps
asset_path: .\${{ env.ZipName }}
asset_name: ${{ env.ZipName }}
asset_content_type: application/zip
Can anyone please recommend a GitHub action for zipping a folder that will work for windows-latest ... or another approach?
Long term I want to go with semantic versioning but GitVersion overwhelmed me last time I tried, granted I'd never working with yml builds before. I'd like to keep this as simple as possible as I'm starting to grok the basics of what's going on and once I get past this I'll start looking into GitVersion.
I'm using a test repository located here so you can see the whole thing.

You may use PowerShell to zip your artifacts using 7Zip. Please check my repository in GitHub. That compile a WPF app, compress the artifacts, create a prerelease and upload files under that release.

Related

GitHub Actions Matrix sharing the Same Code CheckOut

I tried to perform step actions/checkout#v3 once on chained jobs, but it seems like the "build" job does not get the code. I'm getting an error "can't find the project".
Can I call actions/checkout # v3 once for two jobs?
It works when I call the code checkout twice.
name: publish-nuget
on:
push:
branches:
- main
jobs:
prepare:
runs-on: ubuntu-latest
- name: Checkout code
uses: actions/checkout#v3
- name: Get package version
id: get_package_version
uses: kzrnm/get-net-sdk-project-versions-action#v1.3.0
with:
proj-path: ProjectOne.csproj
build:
needs: prepare
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout#v3
# Add the projects path below
strategy:
matrix:
projects: [
'ProjectOne.csproj',
'ProjectTwo.csproj',
]
steps:
- name: Pack NuGet
run: dotnet pack ${{ matrix.projects }} -p:PackageVersion=${{ env.PACKAGE_VERSION }} --configuration Release
It does not work when I call the code checkout once (on the 'prepare' job).
name: publish-nuget
on:
push:
branches:
- main
jobs:
prepare:
runs-on: ubuntu-latest
- name: Checkout code
uses: actions/checkout#v3
- name: Get package version
id: get_package_version
uses: kzrnm/get-net-sdk-project-versions-action#v1.3.0
with:
proj-path: ProjectOne.csproj
build:
needs: prepare
runs-on: ubuntu-latest
steps:
# Add the projects path below
strategy:
matrix:
projects: [
'ProjectOne.csproj',
'ProjectTwo.csproj',
]
steps:
- name: Pack NuGet
run: dotnet pack ${{ matrix.projects }} -p:PackageVersion=${{ env.PACKAGE_VERSION }} --configuration Release
Having a job being dependent on another job, is just for logical purposes and not state or artifact dependency sharing. You are actually runing the 2 jobs on 2 different agents. If you want to share something from the prepare job, you can use the cache or artifact API. E.g. using the cache API to cache the path 'somePath'. Same step for downloading the cache.
- name: Cached build artifacts
uses: actions/cache#v2
id: artifactcache
with:
path: somePath
key: buildArtifacts${{ github.run_number}}
As you are not gaining anything form splitting this up into 2 jobs, I would run everything in a single job instead.

How to set up a monorepo in SonarCloud with a Java + Angular application

I have developed an application where the backend is developed using Java language (with maven) and the frontend is using Angular language. I host both parts in one project in github.
Now I am interested on the use of SonarQube on SonarCloud. For this purpose, I am following the information gathered from the community sonarsource and the standard documentation from sonarcloud. The idea is to use GiHub Actions for analyzing the projects.
What I have created is a .github/workflows/build.yml on the root folder with the content:
name: Build
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
name: SonarCloud
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Set up JDK 11
uses: actions/setup-java#v1
with:
java-version: 11
- name: Cache SonarCloud packages
uses: actions/cache#v1
with:
path: ~/.sonar/cache
key: ${{ runner.os }}-sonar
restore-keys: ${{ runner.os }}-sonar
- name: Cache Maven packages
uses: actions/cache#v1
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
restore-keys: ${{ runner.os }}-m2
- name: Build and analyze
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
run: mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.projectKey=kendo-tournament-backend
with:
projectBaseDir: ./backend/
- name: SonarCloud Frontend Scan
uses: SonarSource/sonarcloud-github-action#master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
with:
projectBaseDir: ./frontend/
Where basically, I create some steps for executing the maven project, and another extra step to execute the frontend. On both of them, I included the projectBaseDir with the path to both projects' folders as specified here.
Also, as suggested on the documentation, I have included a sonar-project.properties on the root folder of the frontend folder with:
sonar.projectKey=kendo-tournament-frontend
sonar.organization=softwaremagico
# This is the name and version displayed in the SonarCloud UI.
#sonar.projectName=Kendo Tournament Manager Frontend
#sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
#sonar.sources=.
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8
And for the backend, I have updated the root pom.xml with the:
<properties>
<sonar.organization>softwaremagico</sonar.organization>
<sonar.host.url>https://sonarcloud.io</sonar.host.url>
</properties>
As required.
But, no analyses scan is launch for any of both projects. And SonarCloud looks like is ignoring the configuration.
Probably, something is missing but I cannot imagine what. What steps are needed to set up a monorepository correctly using Java and Angular in Github?
Ok, after the example obtained from here. The changes I have made are:
Two different workflows on github, one for backend and one for frontend. Not one workflow with all steps together.
Include two different sonar-project.properties. One inside the backend folder, and one inside the frontend folder. Now I have added the sonar.sources line as follows:
sonar.projectKey=kendo-tournament-backend
sonar.organization=softwaremagico
sonar.sources=.
That ensures that is only for this folder.
For launching CircleCi with Sonar (for backend) edit file .circleci/config.yml:
version: 2.1
jobs:
build:
docker:
- image: 'circleci/openjdk:11-jdk'
working_directory: ~/KendoTournamentManager/backend
steps:
- checkout:
path: ~/KendoTournamentManager
- run:
name: Analyze on SonarCloud
command: mvn verify sonar:sonar -Dsonar.projectKey=kendo-tournament-backend
workflows:
main:
jobs:
- build:
context: SonarCloud
And now seems working fine:

GitHub Actions: shared cached gradle dependencies

I'm trying to implement caching for my workflow using actions/cache#v2 (https://github.com/actions/cache) action.
I have a workflow which runs on pull requests.My project has tons of dependencies so it would be a great build time improvement if I could re-use artifacts, downloaded previously. After successful run artifacts got cached within this pull request/branch and can be re-used on next runs for this pull request:
Cache restored successfully
Cache restored from key: Linux-823bfbee4d05185dedf13d718e8e4ff4933074565b84dd636e19434372154c6a-8331f72d4c267e28baf5311f561dc9f09f1813899db5fd4929c70715b85b2934-45275122110c339513af5e3da3a953eed4a843d91a5d03cd48b8a26988749289
From this description: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
I got an impression, that the cache (including gradle dependencies, like libraries etc), once downloaded, should be available for other branches based on my develop, after one of the PRs got merged:
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually main). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch feature-b has the base branch feature-a, a workflow triggered on feature-b would have access to caches created in the default branch (main), feature-a, and feature-b.
But apparently, it doesn't work for me, I'm getting this for all the new PRs:
Run actions/cache#v2
Cache not found for input keys: Linux-823bfbee4d05185dedf13d718e8e4ff4933074565b84dd636e19434372154c6a-8331f72d4c267e28baf5311f561dc9f09f1813899db5fd4929c70715b85b2934-45275122110c339513af5e3da3a953eed4a843d91a5d03cd48b8a26988749289
So I'm getting all the gradle dependencies downloaded, over and over again.
So my question is: is it possible to have the dependencies, once downloaded, be available from cache for all other branches/pull requests. If yes, can this be done using actions/cache#v2 or shall I look to another tasks/tools?
Here's simplified version of my workflow:
name: build-pull-request
on:
pull_request:
types:
- opened
- synchronize
- reopened
branches:
- '**'
workflow_dispatch:
jobs:
verify-pull-request-quality:
name: Verify pull request
runs-on: ubuntu-latest
steps:
- name: Cancel previous runs of this workflow
uses: styfle/cancel-workflow-action#0.9.1
with:
access_token: ${{ github.token }}
- name: Check out ${{ github.ref }}
uses: actions/checkout#v2
- name: Cache gradle dependencies
uses: actions/cache#v2
env:
cache-name: cache-gradle-depedencies
with:
path: |
~/.gradle/caches
~/.gradle/wrapper
key: ${{ runner.os }}-${{ hashFiles('**/*.gradle*') }}-${{
hashFiles('**/gradle/wrapper/gradle-wrapper.properties') }}-${{
hashFiles('**/buildSrc/**/*.kt') }}
- name: Run unit test
uses: gradle/gradle-build-action#v2
with:
build-root-directory: ${{env.working-directory}}
arguments: assemble

Parallelism in CI/CD Pipelines like GitHub Actions

Hello there and thank you for reading my question, its my first one here.
I am working with CI/CD pipelines for a year now and I think they are pretty nice and convinient for developing Websites and Stuff. But in the last months I have more and more problems creating fast, efficient and smart pipelines without redundant dependency installs or similar. So I want to use as less computation ressources as possible while still have fast builds. I want to parallelize steps and use theire artifacts in another final step. For example the following GitHub Actions workflow:
My goal with this workflow is to just build a VueJS Single Page App and deploy it to the IBM Cloud. For that I need to install the npm dependencies and build the Vue App and also install the IBM Cloud CLI. After these two steps are finished the builded App should be pushed to the IBM Cloud.
I could just simply run all steps sequentially like this:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
- name: Install IBM Cloud CLI
run: curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
shell: bash
- name: Install Cloud Foundry CLI
run: ibmcloud cf install
shell: bash
- name: Authenticate with IBM Cloud CLI
run: ibmcloud login --apikey "${{ secrets.IBM_CLOUD_API_KEY }}" --no-region -g Default
shell: bash
- name: Target a Cloud Foundry org and space
run: ibmcloud target --cf-api "${{ secrets.IBM_CLOUD_CF_API }}" -o "${{ secrets.IBM_CLOUD_CF_ORG }}" -s "${{ secrets.IBM_CLOUD_CF_SPACE }}"
shell: bash
- name: Deploy to Cloud Foundry
run: ibmcloud cf push
shell: bash
But in my opinion this is very ugly and can be improved. So I tried to split the job into 3 parts: build, predeploy and deploy. The build job installs and builds the Vue App. The Predeploy job install the IBM CLI. These two jobs doesn't depend on each other so they can be parallized. But the last job, deploy, depends on both so I added the needs: [build, predeploy] value to it. So I have the following workflow to archive this:
### This will not work!
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
predeploy:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
steps:
- name: Install IBM Cloud CLI
run: curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
- name: Install Cloud Foundry CLI
run: ibmcloud cf install
- name: Authenticate with IBM Cloud CLI
run: ibmcloud login --apikey "${{ secrets.IBM_CLOUD_API_KEY }}" --no-region -g Default
- name: Target a Cloud Foundry org and space
run: ibmcloud target --cf-api "${{ secrets.IBM_CLOUD_CF_API }}" -o "${{ secrets.IBM_CLOUD_CF_ORG }}" -s "${{ secrets.IBM_CLOUD_CF_SPACE }}"
deploy:
needs: [build, predeploy]
runs-on: ubuntu-latest
steps:
- name: Deploy to Cloud Foundry
# Error: 'ibmcloud: command not found'
run: ibmcloud cf push
shell: bash
Which looks on the GUI like:
[![My GitHub Workflow on the GUI][1]][1]
But this workflow will error since the last job doesn't share the same environment as the other jobs. I am aware that I could use the up/download Artifact feature of GitHub Actions but this seems to me like using a lot of resources. But I dont want to use a lot of ressources for my pipeline, I dont need a lot of different virtual environments or build matrixes. (I know they are very good for large projects, but they seem a little overkill for my little site)
So here are my two final Questions:
Why is parallelism in CI/CD often complication and not straight forward?
How can I improve my current pipeline with parallelism and without redundant executions?
I am glad about every helpful advice or link. Thank you. :)
[1]: https://i.stack.imgur.com/qEqLs.png
I think your original workflow was already pretty efficient. As you mentioned, different jobs are executed on different runners and sometime the additional complexity and effort put into the synchronization/logic between workflows outweighs the benefits of parallelism. In your case I don't think it would make much sense to run your jobs in parallel.
For your first question, I don't think it's an issue specific to CI/CD pipelines. I am getting a bit out of scope here but you have similar issues in any code that does work in parallel or as a matter of fact in any work in general that is done in parallel anywhere. Being factories, teams, code, CI pipelines, as soon as the work is split up, there will be some sort of mechanism to manage the allocation of work and track its progress. Which will make it more complex.
Why GH workflows might seem less straightforward than other systems seem to be a better question and I think it comes does to how long it has been around. It's a pretty recent addition to github and as new features are progressively being added it gets easier and easier to work with.
Regarding other optimizations for your workflow, I would recommend trying to avoid redoing the same work every time the workflow run if it's not needed. You already do this with the cache action for npm. But you could, for example build a docker image, or even better an action ,with your IBM CLI in it and remove the pre-deploy stage entirely. Simply having:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout#v2
- name: Use Node.js 10.X
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Cache Node Modules
uses: actions/cache#v2
env:
cache-name: cache-node-modules
with:
# npm cache files are stored in `~/.npm` on Linux/macOS
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Install Dependencies
run: npm ci
- name: Build Page
run: npm run build
- name: Deploy to Cloud Foundry
uses: my-action:v1
with:
api-key: ${{ secrets.IBM_CLOUD_API_KEY }}
cf-api: ${{ secrets.IBM_CLOUD_CF_API }}
cf-org: ${{ secrets.IBM_CLOUD_CF_ORG }}
cf-space: ${{ secrets.IBM_CLOUD_CF_SPACE }}

How to push nuget package in GitHub actions

I am trying to use GitHub actions to generate a NuGet package from my project and push it to the (private) GitHub registry.
My script ([NAME] fields redacted):
name: Update NuGet
on: [push]
jobs:
build:
runs-on: ubuntu-latest
name: Update NuGet
steps:
- uses: actions/checkout#master
- uses: actions/setup-dotnet#v1
with:
dotnet-version: '2.2.105'
- name: Package Release
run: |
cd [SOLUTION_FOLDER]
dotnet pack -c Release -o out
- name: Publish Nuget to GitHub registry
run: dotnet nuget push ./[SOLUTION_FOLDER]/[PROJECT_FOLDER]/out/$(ls ./[SOLUTION_FOLDER]/[PROJECT_FOLDER]/out) -s https://nuget.pkg.github.com/[USERNAME]/index.json -k ${GITHUB_TOKEN}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Log output:
info : Pushing [PROJECT_FOLDER].3.4.23.nupkg to 'https://nuget.pkg.github.com/[USERNAME]'...
info : PUT https://nuget.pkg.github.com/[USERNAME]/
info : An error was encountered when fetching 'PUT https://nuget.pkg.github.com/[USERNAME]/'. The request will now be retried.
info : An error occurred while sending the request.
info : The server returned an invalid or unrecognized response.
info : PUT https://nuget.pkg.github.com/[USERNAME]/
info : An error was encountered when fetching 'PUT https://nuget.pkg.github.com/[USERNAME]/'. The request will now be retried.
info : An error occurred while sending the request.
info : The server returned an invalid or unrecognized response.
info : PUT https://nuget.pkg.github.com/[USERNAME]/
error: An error occurred while sending the request.
error: The server returned an invalid or unrecognized response.
##[error]Process completed with exit code 1.
This is the coresponding GitHub issue (with a workaround option): https://github.com/NuGet/Home/issues/8580
Second Update:
I got an answer in the GitHub issue from jcansdale that says (haven't tested this):
Support for the dotnet nuget push --api-key option has now been added to GitHub Packages. For some reason this works consistently, but using basic auth (password in nuget.config file) fails randomly!
Example:
- name: Publish Nuget to GitHub registry
run: dotnet nuget push ./<project>/out/*.nupkg -k ${GITHUB_TOKEN} -s https://nuget.pkg.github.com/<organization>/index.json --skip-duplicate --no-symbols
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Update:
Based on Dids answer on GitHub my configuration works now like this:
name: NuGet Generation
on:
push:
branches:
- master
pull_request:
types: [closed]
branches:
- master
jobs:
build:
runs-on: ubuntu-18.04
name: Update NuGet package
steps:
- name: Checkout repository
uses: actions/checkout#v1
- name: Setup .NET Core # Latest
uses: actions/setup-dotnet#v1
with:
source-url: https://nuget.pkg.github.com/<organization>/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
- name: Build solution and generate NuGet package
run: |
cd <project>
dotnet pack -c Release -o out
- name: Push generated package to GitHub registry
run: dotnet nuget push ./<project>/out/*.nupkg --skip-duplicate --no-symbols true
Note: At the time of writing I needed to use --no-symbols true instead of --no-symbols to prevent exceptions in the dotnet NuGet client.
Old answer:
I switched to the Windows image and got it to work based on the example of #anangaur. This is my final code:
name: NuGet Generation
on:
push:
branches:
- master
jobs:
build:
runs-on: windows-latest
name: Update NuGet
steps:
- name: Checkout repository
uses: actions/checkout#master
# latest image has .NET already installed!
# - name: Setup .NET environment
# uses: actions/setup-dotnet#v1
# with:
# dotnet-version: '2.2.105'
- name: Build solution and generate NuGet package
run: |
cd SOLUTION_FOLDER
dotnet pack -c Release -o out
- name: Install NuGet client
uses: warrenbuckley/Setup-Nuget#v1
- name: Add private GitHub registry to NuGet
run: nuget sources add -name "GPR" -Source https://nuget.pkg.github.com/ORGANIZATION_NAME/index.json -Username ORGANIZATION_NAME -Password ${{ secrets.GITHUB_TOKEN }}
- name: Push generated package to GitHub registry
run: nuget push .\SOLUTION_FOLDER\PROJECT_FOLDER\out\*.nupkg -Source "GPR" -SkipDuplicate
Here is a workaround that works on all platforms:
name: prerelease NuGet
on: [push]
jobs:
build:
runs-on: ubuntu-latest
# also works with windows-latest and macos-latest
steps:
- name: Checkout repository
uses: actions/checkout#v1
- name: Build with dotnet
run: dotnet build --configuration Release --version-suffix prerelease-$(date +%Y%m%d%H%M%S)
shell: bash
- name: Publish nuget
run: |
for f in ./[repository]/bin/Release/*.nupkg
do
curl -vX PUT -u "[user]:${{ secrets.GHPackagesToken }}" -F package=#$f https://nuget.pkg.github.com/[user]/
done
shell: bash
Notes:
this creates a datestamped prerelease build for every git push and uploads it to nuget
for the suffix to work, you need to set <VersionPrefix> instead of <Version> in your .csproj
if you don't want the prerelease suffix, remove the --version-suffix parameter
the shell is explicitly set as bash in order to allow compatibility with building on windows
you will need to replace [user] and [repository] above with your own specific values
you will need to create a personal access token with the permissions of write:packages
then create a GitHub Secret named GHPackagesToken and put the token created above in there
using GitHub Secrets eliminates the need for a separate file containing your token
this assumes you're have <GeneratePackageOnBuild>true</GeneratePackageOnBuild> in your .csproj
if you don't, then you will need an additional step running dotnet pack
make sure to specify <RepositoryUrl>...</RepositoryUrl> in your .csproj
for a working example if you can't get the above code working, see https://github.com/vslee/IEXSharp/blob/master/.github/workflows/dotnetcore.yml, which pushes to https://github.com/vslee/IEXSharp/packages (ignore all of my extraneous comments there)
I posted this bc I tried both the examples from jwillmer above, as well as #anangaur and #marza91 on the GH issue thread but neither worked for me (on any platform)
once GitHub fixes the issue of not being able to use the API key directly in the dotnet nuget push command (see initial post of GH issue), then we won't need this workaround anymore
You can use the dotnet nuget add source command:
- name: NuGet push
run: |
dotnet nuget add source https://nuget.pkg.github.com/${{ github.repository_owner }}/index.json --name github --username ${{ github.repository_owner }} --password ${{ github.token }} --store-password-in-clear-text
dotnet nuget push **/*.nupkg --source github
The --store-password-in-clear-text option was required for me when running in a linux environment.
With this method, there's no need to modify the actions/setup-dotnet task.
Also, this method would allow you to push to multiple NuGet streams if needed.
Make sure you project file has the following
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<OutputType>Library</OutputType>
<PackageId>Example.PackageName</PackageId>
<Version>1.0.0</Version>
<Authors>Author Engineering</Authors>
<Company>Company Inc</Company>
<PackageDescription>This package for ...!</PackageDescription>
<RepositoryUrl>
https://github.com/YOUR_ACCOUNT/Example.PackageName</RepositoryUrl>
</PropertyGroup>
This should be your main.yaml for building, packaging, publishing, and versioning:
name: Continuous Integration
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Setup Dotnet Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: 3.1.100
source-url: https://nuget.pkg.github.com/YOUR_ACCOUNT/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
- name: Setup Nuget Config
run: sed 's/GITHUB_TOKEN/${{ secrets.GITHUB_TOKEN }}/g' .nuget.config > nuget.config
- name: Build
run: dotnet build --configuration Release
- name: Version and Tag
id: bump_version
uses: mathieudutour/github-tag-action#v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Prep Version String
run: echo ::set-env name=VERSION_NUMBER::$(echo ${{ steps.bump_version.outputs.new_tag }} | sed 's/[v]//g')
- name: Define Package Name
run: echo ::set-env name=PACKAGE_NAME::$"Example.PackageName/bin/Release/Example.PackageName.${{ env.VERSION_NUMBER }}.nupkg"
- name: Set Nuget Package Version
uses: roryprimrose/set-vs-sdk-project-version#v1
with:
version: ${{ env.VERSION_NUMBER }}
- name: Pack
run: dotnet pack --configuration Release Example.PackageName
- name: Publish Package
run: dotnet nuget push Example.PackageName/bin/Release/*.nupkg --source https://nuget.pkg.github.com/YOUR_ACCOUNT/index.json
- name: Create Release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ steps.bump_version.outputs.new_tag }}
release_name: Release ${{ github.ref }}
The other answers were so long, I don't know why. This is what I do:
For NuGet.org:
- name: Push Package to NuGet.org
run: dotnet nuget push *.nupkg -k ${{ secrets.NUGET_ORG_API_KEY }} -s https://api.nuget.org/v3/index.json
For GitHub.com:
- name: Push Package to GitHub.com
run: dotnet nuget push *.nupkg -k ${{ secrets.GITHUB_TOKEN }} -s https://nuget.pkg.github.com/USERNAME/index.json
My working solution:
replace 'usernamecompanyname' with a valid value for your repo
I kept the build and pack separated to allow for easier debugging if something goes wrong
you can set ACTIONS_RUNNER_DEBUG variable in your github secrets to true to allow for more detailed debuging
Change dotnet-version to your desired dotnet-sdk version
No need to specify GITHUB_TOKEN in your github repo secrests, this token is present by default
build_and_publish_nuget.yml:
name: Build and publish package
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [ master ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout#master
- name: Setup .NET environment
uses: actions/setup-dotnet#v1
with:
dotnet-version: '3.1.102'
source-url: https://nuget.pkg.github.com/usernamecompanyname/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
- name: Build project
run: dotnet build -c Release
- name: Generate a NuGet package
run: dotnet pack --no-build -c Release -o .
- name: Push to GitHub package registry
run: dotnet nuget push *.nupkg
GitHub has been having intermittent issues with publish NuGet Packages to GitHub Packages. I reached out to support and they gave me two options.
Option 1: CURL
curl -vX PUT -u "<username>:<TOKEN>" -F package=#PATH-TO-PKG-FILE.nupkg https://nuget.pkg.github.com/<OWNER>/
Option 2: DOTNET GPR TOOL
https://github.com/jcansdale/gpr
dotnet tool install gpr -g
gpr push PATH-TO-PKG-FILE.nupkg -k <TOKEN>
I went with Option 2 in my GitHub Action Workflow:
$file = Get-ChildItem -Path <where I output my nupkg file to> -Recurse -Filter *.nupkg | Select -First 1
gpr push $file.FullName -k ${{secrets.GITHUB_TOKEN}}

Resources