Running github actions for `uses` in another directory - maven

My maven repository is in ./java directory. I want to run maven test in ./java directory, but I got following error:
The goal you specified requires a project to execute but there is no POM in this directory (/github/workspace). Please verify you invoked Maven from the correct directory. -> [Help 1]
Here is my workflow:
# This is a basic workflow to help you get started with Actions
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch:
jobs:
build:
defaults:
run:
working-directory: java
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Run maven test
uses: xlui/action-maven-cli#master
with:
lifecycle: 'clean package test'
It seems that working-directory is useless, how can I fix it?

working-directory can only be applied to run: steps (e.g it does not work on actions)
The action xlui/action-maven-cli#master currently doesn't allow to inform a path to execute the maven commands.
You could either
use another (similar) action available on the Github Marketplace which allows to inform a directory path before executing maven commands,
open a PR to update the xlui/action-maven-cli action, adding an input path (or env variable) to perform a cd command before executing the maven commands,
install maven directly on your workflow within a step(for example setup maven action), before running the maven command directly on another step (without uses the action) with run: | with a cd ./java before executing sh -c "mvn clean package test",
Something like this (for the 3rd option):
steps:
- uses: actions/checkout#v2
- name: Install maven
run: |
...
- name: Run maven command
run: |
cd ./java
mvn clean package test

Related

Why is it possible to run Go tests and builds inside CI environments without having to install the dependencies first?

I have a Go project with a Makefile
test:
#go test -cover ./...
and a mod file
module path/to/repo
go 1.19
require github.com/go-chi/chi/v5 v5.0.8
I created a Github action sample to run tests on a Github PR
name: QA on pull request
on: pull_request
jobs:
run-tests:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout#v3
with:
fetch-depth: 0
- name: Setup Go
uses: actions/setup-go#v3
with:
go-version: 1.19
- name: Run tests
run: make test
I would like to know why this workflow is working without a install dependencies step. The project itself is using external dependencies and I think there should be a step that runs go get ./...
Does Go install them under the hood if not present? Or does the action actions/setup-go#v3 install the dependencies?
According to go test docs (or you may run go help test locally to read its description):
'Go test' recompiles each package along with any files with names matching the file pattern "*_test.go".
It also installs all the dependencies; so, it happens when the action does go test. You can probably observe it in the logs.
actions/setup-go#v3 doesn't depend on the code itself. It just sets up the go environment you ask for. In your setup, if you swap the setup-go and checkout, it still works.

How to include xml file from other project in gitlab ci pipeline?

I have a project /templates where I want to add a common ci_settings.xml that sets some defaults for maven commands.
I then want to reuse this template in another project:
.gitlab_ci.yml:
image: maven:3.8.4-eclipse-temurin-11
include:
project: 'all/templates'
ref: master
file:
- 'ci_settings.xml'
deploy:
stage: deploy
script: mvn deploy -s ci_settings.xml
Result:
Found errors in your .gitlab-ci.yml:
Included file `ci_settings.xml` does not have YAML extension!
How can I actually make use of this external file, if not via include?
You can use include only with yml files. But you can clone the /templates project in your pipeline via CI_JOB_TOKEN and use it this way. As you don't need the commit history here you can set the depth to 1.
image: maven:3.8.4-eclipse-temurin-11
deploy:
stage: deploy
script:
- git clone --depth 1 https://gitlab-ci-token:${CI_JOB_TOKEN}#your_path_to_templates_project.git templates
- mvn deploy -s templates/ci_settings.xml

How can I make GitHub actions give me a jar file not a zip?

I set up github actions for my java repo (a spigot plugin) but it always gives me a zip file with the jar I want inside it, when it should just be giving me the jar. Is there any way to make it just give me a jar?
name: Build plugin
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Set up JDK 1.8
uses: actions/setup-java#v1
with:
java-version: 1.8
- name: Build with Maven
run: mvn -B package --file pom.xml
- name: Archive artifacts
uses: actions/upload-artifact#v2
with:
name: GeyserUpdater
path: |
target/*.jar
!target/original-*.jar
During a workflow run, files are uploaded and downloaded individually using the upload-artifact and download-artifact actions. However, when a workflow run finishes and an artifact is downloaded from either the UI or through the download api, a zip is dynamically created with all the file contents that were uploaded. There is currently no way to download artifacts after a workflow run finishes in a format other than a zip or to download artifact contents individually. One of the consequences of this limitation is that if a zip is uploaded during a workflow run and then downloaded from the UI, there will be a double zip created.
https://github.com/marketplace/actions/upload-a-build-artifact

How to use bitbucket pipeline to generate war file and copy it to downloads?

I want to use bitbucket as a maven repository for a personal project. My plan is to use bitbucket pipelines to build the project and copy the war file to the downloads page. After the build finishes successfully, I get the following message:
Building war: /opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war
but when the second pipeline is run to copy the war, I get the following:
File opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war doesn't exist.
Also the artifacts tab is empty.
bitbucket_pipelines.yaml:
image: maven:3.6.3
pipelines:
default:
- step:
name: Build and Test
caches:
- maven
script:
- mvn clean compile package
artifacts:
- opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war
- step:
name: Generate and deploy war
script:
- pipe: atlassian/bitbucket-upload-file:0.3.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
FILENAME: "opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war"
If you sure that your path is correct, try to clean bitbucket maven cache.
You can find it on Pipelines -> Caches
The problem is here:
opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war
You have removed the "/" at the beginning of the path string, which makes it a relative path to the current directory. Try something like this, to use an absolute path:
/opt/atlassian/pipelines/agent/build/todoey-be/target/todoey.war
However, instead of using a hard-coded full path, there is a better way to use a relative path with some environment variables, and also to add some temporary debug lines to verify the path. Consider something like this:
script:
- mvn clean compile package
# Now verify the path of the built WAR output file
- echo $BITBUCKET_CLONE_DIR # Debug: Print the Git clone directory
- pwd # Debug: Print the current working directory
- find "$(pwd -P)" -name todoey.war # Debug: Show the full file path of todoey.war, from the current working directory
- echo "$BITBUCKET_CLONE_DIR/build/todoey-be/target/todoey.war" # Debug: Print the resolved path of todoey.war
artifacts:
- "$BITBUCKET_CLONE_DIR/build/todoey-be/target/todoey.war"
- pipe: atlassian/bitbucket-upload-file:0.3.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
FILENAME: "$BITBUCKET_CLONE_DIR/build/todoey-be/target/todoey.war"
$BITBUCKET_CLONE_DIR is a pre-defined environment variable to your project's 'Git clone' root folder: It's described here: https://support.atlassian.com/bitbucket-cloud/docs/variables-in-pipelines/
Update 5 December 2022: The guideline on Bitbucket Artifacts says that you must only use relative paths for the artifacts: step, but you can use full paths for the pipe: step. So something like this:
image: maven:3.6.3
pipelines:
default:
- step:
name: Build and Test
caches:
- maven
script:
- mvn clean compile package
artifacts:
# Use a relative path here
- build/todoey-be/target/todoey.war
- step:
name: Generate and deploy war
script:
- pipe: atlassian/bitbucket-upload-file:0.3.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
# Use the full path here, with an environment variable
FILENAME: "$BITBUCKET_CLONE_DIR/build/todoey-be/target/todoey.war"

SonarCloud code coverage remains 0.0 in GitHub Actions build

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 }}

Resources