I'm trying to wrap my head around GitHub actions as well as how YAML is parsed.
For obvious reasons, I'd like to make use of actions already available on the marketplace. This is what I have so far..
- name: Bump Version
on:
pull_request:
branches:
- main
jobs:
bump-patch:
runs-on: ubuntu-latest
steps:
- name: Get current package version
uses: martinbeentjes/npm-get-version-action#v1.1.0
with:
# Path to package.json file (directories only), e.g. packages/mypackage/
path: ./
- name: Bump Patch Version
uses: jessicalostinspace/bump-semantic-version-action#v1.0.1
with:
semantic-version: 1.0.0
version-type: PATCH
So a few obvious things.. I need to read the current package/bower version in order to Bump it correctly with the action. I also need to make sure the branch in the PR is the one that gets updated and commits the change to that branch. Additionally the action should only run depending on the user who opened the PR.
The question:
Is it even possible to do this with GitHub actions or would a github app/service be better suited?
Related
I have a repository with Dependabot in it, that opens PR on version updates, etc which I would like to keep.
In the same repository, I have a GitHub Action for Pull Requests for my team to use.
My issue is that the Dependabot keeps triggering the Pull Request action no matter what I tried.
My PR action have to be triggered on staging branch pull requests, like so:
name: Pull Request
on:
pull_request:
branches:
- staging
So I can't use both on pull_reuqest AND branches_ignore - as stated in the documentation
Workflow attempts I have tried so far that unfortunately haven't worked:
name: Pull Request
on:
pull_request:
branches:
- staging
- '!dependabot/**'
name: Pull Request
on:
pull_request:
branches:
- staging
jobs:
Build:
if: github.actor!= 'dependabot-preview[bot]'
name: Build
runs-on: ubuntu-latest
steps:
- name: Check out code
uses: actions/checkout#v2
I have also tried excluding the Dependabot user like so:
if: github.actor!= 'depbot'
Would love some insights or answers on how you have dealt with this issue.
Thanks!
I guess there were many changes over the years and you can find outdated ways all over the web. The actual way is documented in the Dependabot documentation
if: ${{ github.actor != 'dependabot[bot]' }}
Note that nowadays you can also check the github.triggering_actor - if you want workflow to be skipped if Dependabot triggered it, but want to be able to manually trigger it on a PR that was opened by Dependabot
I'm experimenting with setting up GitHub Classroom (after getting really tired of manually running tests for student submissions this term). I picked one of the tests from the class I am just finishing, but for the test script I have there, I need Python 3.10; earlier versions won't do.
I tried setting up .github/workflows/classroom.yml to specify the Python version. If I set it to this, in a student repository, I can get my tests to run:
name: GitHub Classroom Workflow
on: [push]
jobs:
build:
name: Autograding
runs-on: ubuntu-latest
steps:
- uses: actions/setup-python#v2
with:
python-version: "3.10"
- uses: actions/checkout#v2
- uses: education/autograding#v1
but (of course) I don't want my students to do this manually whenever they check out an assignment. So, I tried adding the same to the template repository, but that doesn't seem to affect the student repository when I make a new one of those. There, I get the default I got before
name: GitHub Classroom Workflow
on: [push]
jobs:
build:
name: Autograding
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: education/autograding#v1
Is there a way to specify what the workflow should be for an assignment or classroom? Or a way to get it from the template?
Or a way to get it from the template?
Your template could include a workflow, meaning reuse an existing workflow (possible since Oct. 2021)
The "Reusable workflows and workflow templates" section includes:
Inside workflow templates, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code.
If your reusable workflow comes with the right python-version, nothing will have to be set up manually.
I'm currently using the "git-flow" branching model outlined here. Following that model, once I've completed work on a feature branch, I'd like to add new GitHub actions to that branch (for example, to run my feaure's automated tests) before the branch is merged.
Following the branching model, I don't want to define the actions in a workflow file on the default branch before that feature branch is merged into it. Ideally I want to add the actions on the feature branch itself before the merge, but this doesn't appear to work.
I've added the below sample workflow to my feature branch, but GitHub does not detect it. Am I missing something here, or can workflows only detected and run once they're on the default branch? If the latter is true, do people generally merge their branches, then add workflows for them?
# Name workflow
name: Test workflow
# Read only permissions
permissions: read-all
# Triggered once every 15 minutes
on:
workflow_dispatch:
schedule:
- cron: '15 * * * *'
# Listing of jobs to be run
jobs:
# Just output the Python version for now.
python-tests:
name: Python Tests
runs-on: ubuntu-latest
# Use the environment configured with secrets
environment: python-test-environment
# Set the working directory?
defaults:
run:
working-directory: tests
steps:
# Checkout the repository
- name: Checkout
uses: actions/checkout#v2
ref: 'dev-tests'
# Configure Python
- name: Set up Python 3.7
uses: actions/setup-python#v2
with:
python-version: 3.7
# Output the Python version
- name: Display version
run: python -c "import sys; print(sys.version)"
Update: I can see now that the "schedule" trigger only works on the default branch. However, removing it and just using the workflow_dispatch trigger still (on the feature branch YML file) still does not show the workflow on GitHub.
I have a GitHub repository consisting of LaTeX code for my resume. Currently, I'm including the generated PDF file as a file in git, i.e. it's tracked in version control. The only purpose of including the PDF is to have a link to the latest resume PDF that I can send to people. Hence, I don't really need to track a binary file in version control at all.
Is there a way to get rid of tracking this binary through git? I'm thinking of generating the PDF with GitHub Actions, then uploading it somewhere. This way I don't have to include the PDF in git, while having a link to the latest build (off the master branch) that I can share. Does GitHub have a place where I can keep this PDF?
I've noticed that most GitHub release assets are available through a link like https://github.com/owner/repo/archive/file.tar.gz. Since I just want to maintain a single copy that is built with every commit, using GitHub releases would be overkill for this. Can I somehow "dump" the PDF from the latest build in https://github.com/me/resume/archive/resume.pdf? If not, is there any other way?
Your best bet is to have a single release and update that file again and again.
There's also artifacts for GitHub Actions, but they can only be downloaded by logged-in users.
Following up on #riQQ's answer, I was able to automate this using GitHub Actions. Here's a sample workflow YAML file:
name: Update binary
on:
push:
branches:
- master
jobs:
build:
name: Update binary
runs-on: ubuntu-latest
steps:
# Checkout the repo at the commit which triggered this job
- name: Set up git repo
uses: actions/checkout#v2
with:
fetch-depth: 0 # used to get the tag of the latest release
# TODO: Action for compiling and generating the binary
- name: Compile code
# Removes the latest release, so that we can create a new one in its place
- name: Delete latest release
uses: ame-yu/action-delete-latest-release#v2
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# (optional) Removes the tag associated with the latest release
- name: Delete release tag
run: |
git tag -d release
git push origin :release
continue-on-error: true # in case there's no existing release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# Creates the new release with the binary as a release asset.
# If the previous Action was skipped, then this keeps the same tag as the
# previous release.
- name: Create new release
uses: softprops/action-gh-release#v1
with:
body: "Release notes"
name: Latest
tag_name: release
files: /path/to/binary
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NOTE: This approach only works if you want to maintain a single release for the sole purpose of maintaining the binaries as release assets.
The binary will now be visible in the releases page, and its URL can be obtained.
I just started to migrate all my GitLab repositories to GitHub. I wasn't using GitHub for a while so I stumbled over the - at least for me new feature - GitHub Actions.
Since I just started a new project, I wanted to use GitHub Actions for build and deploy my new application. I've really no idea what I'm doing wrong, I'll attach my workflow file below.
What I want to achieve is, everytime I push to a branch that's not my master and that hasn't the prefix 'release/', I want to execute this build and deploy for my development system. Later I will also setup the same script but for a staging (pre production) system ONLY if I push into a branch with the prefix 'release/' and indeed the same a thrid time for production for the master branch only.
What I'm wondering about is, the actions get - at least for my understanding - executed sporadically. I want an behaviour like I had in GitLab: Everytime I push a feature branch or whatever from my local working machine, the development pipeline should get executed. Then I'll create a pull request. Only if the pipeline was successful, I want to be able to merge. After the merge into a branch (for example feature/... into develop), I would like to automatically execute the pipeline for development.
I'm not even sure if this is possible. Maybe I also didn't understood the concept of actions correctly.
name: Publish Development
on:
push:
branches:
- '**'
- '!master'
- '!release/**'
pull_request:
branches:
- '**'
- '!master'
- '!release/**'
jobs:
build-and-deploy:
name: Build and Deploy
runs-on: ubuntu-latest
steps:
- name: check out repository
uses: actions/checkout#v2
with:
token: ${{ secrets.PRIVATE_ACCESS_TOKEN}}
- name: install dependencies
run: npm install
- name: install dependencies
run: npm --prefix ./functions install ./functions
- name: deploy to firebase
uses: w9jds/firebase-action#master
with:
args: deploy
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
PROJECT_ID: ${{ secrets.FIREBASE_PROJECT_ID }}
Thanks!
EDIT: Well it turned out that I just started to try new technology during some service interruption. GitHub was experiencing some issues in their infrastructure. Its working now as expected.
Well it turned out that I just started to try new technology during some service interruption. GitHub was experiencing some issues in their infrastructure. Its working now as expected.