I am trying to implement github actions on a .NET Framework project (v4.7.2).
Everything works until the Build step, where some references are missing. Those references haven`t been added on the project using nuGet. They are local references that were added from other directories.
This is my code:
# This is a basic workflow to help you get started with Actions
name: mySolution.CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
Build:
# The type of runner that the job will run on
runs-on: windows-latest
steps:
- name: Checkout
uses: actions/checkout#v2
- name: Setup MSBuild.exe
uses: microsoft/setup-msbuild#v1.0.2
- name: Setup NuGet
uses: NuGet/setup-nuget#v1.0.5
- name: Restore nuGet packages
run: nuget restore mySolution.sln
- name: Run MSBuild
run: msbuild mySolution.sln /t:Clean,Build /p:platform="Any CPU" /p:Configuration=R2020
So, my question is how to find these references? (assuming that is the problem) any other suggestion?
Thanks.
You have to be sure that files which are references by your project are available on build agent. So if you didn't add them to the repo please add them or make them available on build agent in another way.
Related
This question already has an answer here:
GitHub Actions auto-approve not working on pull request created by GitHub Actions bot
(1 answer)
Closed 7 months ago.
I implemented a workflow that runs once a week and updates all the project dependencies and opens a PR with its changes using the workflow token.
name: Automatic dependency update
"on":
workflow_dispatch: null
schedule:
- cron: 0 0 * * 1
jobs:
update:
name: Update to latest versions
runs-on:
- self-hosted
- default-runner
steps:
- name: Checkout Project
uses: actions/checkout#v2
- name: Install Java
uses: actions/setup-java#v2
- name: Update Versions
run: |
./gradlew useLatestVersions --info
- name: Commit and open PR
uses: peter-evans/create-pull-request#v3
with:
commit-message: Update to latest versions
committer: Update Bot <workflow#xxx.com>
branch: auto-dependency-update
base: dev
delete-branch: true
title: Automatic dependency update
draft: false
team-reviewers: XX/teamname
body: Automated gradle dependency updates
The issue is, that for this PR the normal workflows (that are mandatory for the PR merge are not triggered.
name: Build pipeline
"on":
workflow_dispatch: null
pull_request:
branches:
- dev
push:
branches:
- '!master'
- '**'
defaults:
run:
shell: bash
jobs:
build:
name: Compile
runs-on:
- self-hosted
- default-runner
steps:
- name: Checkout code
uses: actions/checkout#v2
- uses: actions/setup-java#v2
- name: Compile code
run: |
./gradlew classes testClasses --info
# ...
When I manually push something to that branch, the workflows are triggered. Though when I add the following step to the version update workflow, then the workflows aren't triggered either.
So what can I do? I dont want to trigger the workflows explicityl (e.g. using benc-uk/workflow-dispatch#v1) to keep the update mechanism as generic as possible.
According to the official documentation
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run.
This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
For more information, see "Authenticating with the GITHUB_TOKEN."
The action you're using to open the PR also states in the Inputs section that you can change the GITHUB_TOKEN scope as well, or use a PAT:
GITHUB_TOKEN (permissions contents: write and pull-requests: write) or a repo scoped Personal Access Token (PAT).
Solution
Therefore, you just need to add a token input to the peter-evans/create-pull-request action using a secret allowing you to trigger a workflow from another workflow.
I'm setting up Github action to lint the OpenAPI Spec using Spectral. Before linting, I would like to generate the single file spec and commit it.
I have set up a workflow that will first build and then lint. But the problem is, the lint is not considering the commit made by Github action in the previous step. It always lint for the commit that triggered this action. Is there any way to lint with the commit made as part of Github action?
You can see from the above image that Github workflow didn't run for the commit made by Github action.
Workflow file:
name: Run Spectral
on:
- pull_request
jobs:
build:
name: Build Spec
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout#v2
- name: Set up Node.js
uses: actions/setup-node#v1
with:
node-version: 12.x
- name: Install dependencies
run: npm install
- name: Build spec file
run: npm run build
- name: Commit build changes
uses: EndBug/add-and-commit#v7
with:
default_author: github_actions
message: 'Compiled spec file'
add: '_build/oas.yaml'
lint:
name: Lint
runs-on: ubuntu-latest
needs: build
steps:
- name: Checkout Repository
uses: actions/checkout#v2
- name: Spectral Linting
uses: stoplightio/spectral-action#v0.7.3
with:
file_glob: '_build/oas.yaml'
That's because commits made using the standard GITHUB_TOKEN aren't triggering workflows; you have to use a personal access token for an automated workflow that's supposed to kick off another workflow.
Quoting from the docs (linked above):
When you use the repository's GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. [...]
If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. [...]
I am getting the following error message on github actions when msbuild is run for my xamarin.android project:
_ResolveAndroidTooling:
Found Java SDK version 14.0.2.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Legacy.targets(248,5): error XA0030: Building with JDK version `14.0.2` is not supported. Please install JDK version `11.0`
my actions.yaml looks like this:
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the master branch
push:
branches: [ master ]
pull_request:
branches: [ master ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
Android:
runs-on: macos-latest
steps:
- uses: actions/checkout#v2
- uses: actions/setup-java#v2
with:
distribution: 'adopt' # See 'Supported distributions' for available options
java-version: '11'
#- run: java -cp java HelloWorldApp
- uses: taori/xamarinandroid-signedbuild-action#v10
with:
csproj_path: src/Droid.csproj
signing_keystore: ${{ secrets.ANDROID_KEYSTORE }}
keystore_password: ${{ secrets.ANDROID_KEYSTORE_PASS }}
signing_key_alias: ${{ secrets.ANDROID_KEY_ALIAS }}
signing_key_password: ${{ secrets.ANDROID_KEY_PASS }}
configuration: "Release"
mono_version: "stable"
xamarin_android_version: "stable"
- uses: actions/upload-artifact#v2
with:
name: ipa
path: src/*.Droid/bin/Android/Release/**Signed.apk
Does actions/setup-java#v2 not install 11.x? Or is this an issue with msbuild not picking up on the environment variables set by that action?
References
Known issue for azure pipelines
Does actions/setup-java#v2 not install 11.x?
It should, since PR 132 and v2.
Try and simplify your action, to only keep the java installation part, and validate it does work:
- name: setup-java
uses: actions/setup-java#v2-preview
with:
distribution: 'adopt'
java-version: '11'
Then add back the other elements of your original action, and see when the issue manifests itself again.
I recently hooked up my project with github actions for continuous integration. I created two separate jobs: the first one checks if the code in the pull request is accepted by our linter, and the second one checks if the code passes the test suite. I like that having two jobs like this shows up as two separate checkmarks in the Github webpage for the pull request:
The problem I'm having now is that there is some duplicated code in workflow YAML file: the first 3 steps, which install Lua and Luarocks. Not only is it annoying to maintain, but it also wastes CI minutes by running the same actions twice. Is there a way to avoid this? So that the setup code is only written in one place, and only runs once when the workflow executes?
But I am confused what would be the proper way to proceed:
Should I create my own Github Action with the shared setup code?
Should I create a Docker image that already has Lua and Luarocks pre-installed?
Should I use a single job? Can I still have independent checkmarks for the linter and the test suite if they are steps of the same job?
Something else?
Here is the current YAML file for my workflow:
name: Github Actions CI
on: [ pull_request ]
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- run: luarocks install luacheck
- run: ./run-linter.sh
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- run: luarocks install busted
- run: ./build-project.sh
- run: ./run-test-suite.sh
I tried searching for similar questions but couldn't find anything that exactly answered my question:
Caching APT packages in GitHub Actions workflow: I can't use this solution because I don't have a way to precisely specify all the versions of all the dependencies that I am using, so that they may be cached. I also don't mind if separate runs of the workflow are not cached. I'm more worried about the code duplication.
Github actions share workspace/artifacts between jobs? I don't want to have to manage uploading uploading artifacts to a separate service and then deleting them afterwards.
Reuse portion of github action across jobs: In that question the only difference between the jobs is a single variable, so accepted answer is to use a build matrix. But I don't think a build matrix would work as well in my case, where only the setup code is the same?
As of today (August 2021) composite action is no longer limited to run. GitHub Actions: Reduce duplication with action composition
name: "Publish to Docker"
description: "Pushes built artifacts to Docker"
inputs:
registry_username:
description: “Username for image registry”
required: true
registry_password:
description: “Password for image registry”
required: true
runs:
using: "composite"
steps:
- uses: docker/setup-buildx-action#v1
- uses: docker/login-action#v1
with:
username: ${{inputs.registry_username}}
password: ${{inputs.registry_password}}
- uses: docker/build-push-action#v2
with:
context: .
push: true
tags: user/app:latest
Old Answer
What you are looking for is composite action which help you reuse once defined set of steps.
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: octocat/say-hello#v1
- run: luarocks install luacheck
- run: ./run-linter.sh
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: octocat/say-hello#v1
- run: luarocks install busted
- run: ./build-project.sh
- run: ./run-test-suite.sh
octocat/say-hello/action.yml:
runs:
using: "composite"
steps:
- run: echo "Nice to meet you!"
shell: pwsh
For more details you can also check's ADR here.
And why you can't simply run it once for all jobs, because each job may run on a different machine.
A job is a set of steps that execute on the same runner. By default, a workflow with multiple jobs will run those jobs in parallel. You can also configure a workflow to run jobs sequentially. For example, a workflow can have two sequential jobs that build and test code, where the test job is dependent on the status of the build job. If the build job fails, the test job will not run.
There are 3 main approaches for code reusing in GitHub Actions:
Reusable Workflows
Dispatched workflows
Composite Actions
There is an article describing their pros and cons.
In your case if the duplicated steps are in the single workflow you also can:
extract them to the "preparation" job
upload build artifacts
add "preparation" job to "needs" key of both jobs
download build artifact in both jobs
The below code snippet should do the work for you. Instead of creating two jobs, one for lint and another for test, you can use one job and create multiple tasks
name: Github Actions CI
on: [ pull_request ]
jobs:
lint:
name: Lint and Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: leafo/gh-actions-lua#v8.0.0
- uses: leafo/gh-actions-luarocks#v4.0.0
- name: Install Luacheck
run: luarocks install luacheck
- name: Run Lint Check
- run: ./run-linter.sh
- name: Install Busted
run: luarocks install busted
- name: Build Project
run: ./build-project.sh
- name: Run Test Suite
- run: ./run-test-suite.sh
As I have repetitve steps in my Github Actions, I would like to create a template. Let's make a example
name: ci
on: ["push"]
jobs:
build-and-test:
strategy:
matrix:
os: [ubuntu-latest]
runs-on: ${{ matrix.os }}
steps:
- name: checkout
uses: actions/checkout#v1
- name: do stuff
run: |
bash stuff
Is it possible to save only the steps in a separated file? And import afterwards?
Unfortunately it does not look like github-actions supports reusing workflows. Not even YAML anchors are supported.
It looks like the only way to share steps (not setup) is to create actions.
Update: A storm brewing
I have also caught wind of the possibility of reusing actions. Follow the issue to stay up-to-date.
I mentioned in "Reuse portion of GitHub action across jobs" that reusing GitHub Worfflow is now (Oct. 2021) available.
The documentation "Reusing workflows" includes a section "Reusable workflows and workflow templates", which leads to "Creating workflow templates"
If you need to refer to a repository's default branch, you can use the $default-branch placeholder.
When a workflow is created using your template, the placeholder will be automatically replaced with the name of the repository's default branch.
For example, this file named octo-organization-ci.yml demonstrates a basic workflow.
name: Octo Organization CI
on:
push:
branches: [ $default-branch ]
pull_request:
branches: [ $default-branch ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Run a one-line script
run: echo Hello from Octo Organization