My project contains a submodule that holds LFS files:
mainproject/
submodule/
path/to/lfs/file
QUESTION: How do I ensure the LFS files in the submodule are pulled? (Currently they aren't)
In my main.yml file, I do the following:
jobs:
steps:
...
- uses: actions/checkout#v2
with:
lfs: true
token: ${{ secrets.ACCESS_TOKEN }}
submodules: recursive
fetch-depth: 0
This used to work, but I started getting errors a few weeks ago that I root-caused to the LFS files not being pulled.
This is really weird and appears to be undocumented.
I did a little bit of fishing inside my self-hosted runner, and it turns out there's a _work/ inside the github-runner directory where the runner clones repos. This folder gets mapped to /_work/ when running inside a Docker container.
Somewhere along the way, the repos must have broken and git lfs pull stopped updating the latest files.
The solution was to log into the runner and wipe out the repos from under _work/.
Related
My workflow has automatic packaging and upload steps that package build artifacts and upload them to the workflow page. I also manually create releases.
I would like to do the following:
when I push to the tag that was created with a given release,
I would like to upload the zipped artifact file to that release, so users can download
the artifact. Any tips on how to do this ?
Here is my build yaml file.
Thanks!
Turns out it's dead simple to do this:
- name: upload binaries to release
uses: softprops/action-gh-release#v1
if: ${{startsWith(github.ref, 'refs/tags/') }}
with:
files: build/FOO.zip
It seems the action (softprops/action-gh-release#v1) mentioned also creates a release. But there is a much simpelere way upload an artifact to a release without the need of introducing action. The gh cli which is by default available on a GitHub hosted runners can upload the artifact for you.
assets:
name: upload assets
runs-on: ubuntu-latest
permissions:
contents: write # release changes require contents write
steps:
- uses: actions/checkout#v3
- name: Upload Release Asset
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run:
gh release upload <release_tag> <a_file>
Checkout full release example here.
I noticed when I was trying to run my github workflow to deploy my dockerized VUE app to Elastic Beanstalk that I kept getting an error in my logs saying no eslint config found, since I had just a handful of ignore lines.
So when I added a step in the workflow to ls the files being checked out, I saw it did not grab any of the files formatted as .*.
I would assume it should at least be getting the .eslintrc.* file since it is supposed to come featured to run npm install and npm run lint it would look at the checked out config file to determine if the rules pass.
Here is my workflow up to this point:
name: Deploy to Staging Environment
on: [workflow_dispatch]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout Latest Repo
uses: actions/checkout#v2
- name: List Checked Out files
run: ls
# DOES NOT SHOW ANY .* files checked out
Is anyone else noticing the same? What should I try?
I have private repo A (which is a library) and that repo has releases. Now I have repo B which has a dependency on the artifacts of A. The dependency (i.e. which version) is stored in a json file in B. What I'm looking for is a way to download the artifacts of release X from repo A in an action/workflow in repo B.
I have seen a lengthy bash script which make this possible, but I'm wondering if there are off the shelf actions around.
If you are using a Linux runner, you can use the Fetch Github Release Asset action.
uses: dsaltares/fetch-gh-release-asset#master
with:
repo: "user/repo"
version: "tags/v1"
file: "filename.ext"
target: "targetFolder/targetFileName.ext"
token: ${{ secrets.PAT_TO_ACCESS_PRIVATE_REPO }}
Inputs
token
Required The GitHub token. Typically this will be ${{ secrets.GITHUB_TOKEN }}
file
Required The name of the file to be downloaded.
repo
The org/repo containing the release. Defaults to the current repo.
version
The release version to fetch from in the form tags/<tag_name> or <release_id>. Defaults to latest.
target
Target file path. Only supports paths to subdirectories of the GitHub Actions workspace directory
I'm trying to build a repository which allows me to build Docker images for different versions of a project I'm forking.
The repo should have the following layout:
main branch where the workflow is defined, with a trigger such as:
on:
push:
branches-ignore:
- main
The workflow builds the software from any branch (basically a mvn clean package, docker build and docker push that applies to all versions of the software)
many software-1.2.3 branches which don't contain any .github/workflow files (it would be cumbersome to copy this file into each branch, and maintain it there)
From my research so far, it seems that GitHub Actions only runs when a workflow definition is present. However, I wonder if there's a way using webhooks or something to trick the system into doing what I want.
My next best option would probably be using workflow_dispatch,
on: push !main wouldn't work, because that !main branch would need to have this workflow in it.
Running the workflow manually is the easiest solution to implement.
on:
workflow_dispatch:
inputs:
BRANCH_OF_FORK:
description: 'branch name, on which this pipeline should run'
required: true
jobs:
doSomething:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
ref: ${{ github.event.inputs.BRANCH_OF_FORK }}
- run: docker build something something
There's a on:fork event, that could be used to trigger a run, but it could only trigger a fork event of this specific branch, that has the on:fork code in it's workflow.
It's possible to run the workflow on a cron job without on-fork event, but you would have to pick the correct branch programmatically.
steps:
- id: branch-selector
run: |
git clone ${{ github.event.repo.url }} .
all_branches=`git branch --all | grep -v " main\$" | grep -v "/main\$"`
correct_branch=`pick_correct_branch.py $all_branches`
git checkout -b $correct_branch
- run: docker build something something
pick_correct_branch.py is left as an exercise for the reader to implement.
I've noticed that GitHub action does not fail as expected. The same shell script is used in bitbucket pipeline and it fails there as expected.
The script is https://github.com/pavelfomin/gphoto-manager/blob/master/scripts/check-release.sh.
It returns 1 if the version in the pom.xml exists as a tag already.
I've tested the script locally and it does return 1 when tag already exists.
GitHub action: https://github.com/pavelfomin/gphoto-manager/actions/runs/570220185
https://github.com/pavelfomin/gphoto-manager/blob/master/.github/workflows/maven.yml
BitBucket pipeline: https://bitbucket.org/pvlf/gphoto-manager/addon/pipelines/home#!/results/2
https://github.com/pavelfomin/gphoto-manager/blob/master/bitbucket-pipelines.yml
What am I missing?
The issue is caused by actions/checkout#v2 fetching the git repository with --depth=1 and without fetching the tags by default. The solution is to specify fetch-depth: "0"
- uses: actions/checkout#v2
with:
# 0 indicates all history for all branches and tags
fetch-depth: "0"