I'm trying to call multiple workflows from a single one and I want to use the commit sha, or the branch name or something to get the workflow file with the recent changes on the branch the workflows are triggered on.
For example, I am on a branch <feature_branch> and I want to trigger the workflow's on that branch. I want the content of the later called workflows also to be the one from that branch. For that reason, I tried the following:
// My repository structure's essential part
repo_folder
> .github
| > workflows
| | > main-ci.yml
| | > other-workflow.yml
# main-ci.yml
name: Main CI workflow
on: ...
jobs:
uses: <my_repo>/.github/workflows/other-workflow.yml#$GITHUB_REF
...
# other-workflow.yml
...
The issue is that when GitHub parses the main-ci workflow it doesn't seem to resolve the $GITHUB_REF environment variable before trying to call the workflow, and reports a problem
error parsing called workflow "<my_repo>/.github/workflows/other_workflow.yml#$GITHUB_REF": failed to fetch workflow: reference to workflow should be either a valid branch, tag, or commit
I tried with context variables too (like ${{ github.sha }}) but with that syntax, it asks for removing the spaces from the version field.
Just figured this out after heading out to the workflow syntax section of the GitHub actions' documentation. It says:
If you use the second syntax option (without {owner}/{repo} and #{ref}) the called workflow is from the same commit as the caller workflow.
And the example shows
jobs:
call-workflow-1-in-local-repo:
uses: octo-org/this-repo/.github/workflows/workflow-1.yml#172239021f7ba04fe7327647b213799853a9eb89
call-workflow-2-in-local-repo:
uses: ./.github/workflows/workflow-2.yml
call-workflow-in-another-repo:
uses: octo-org/another-repo/.github/workflows/workflow.yml#v1
So, all I needed to do is to change
uses: <my_repo>/.github/workflows/other-workflow.yml#$GITHUB_REF
to
uses: ./.github/workflows/other-workflow.yml
Related
I have configured a manual workflow and it runs OK, but once I update/edit it and commit it to the same branch, the changes do not affect it. I mean the action still runs but uses the old version of the workflow file. is there any step I need to do?
Steps I followed for editing the workflow file:
https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#browsing-marketplace-actions-in-the-workflow-editor
Here is workflow file details, just in case
The original:
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "development" branch
release:
types: [created]
# 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:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout#v3
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world Nikzad!, 3
Note: Let's say I just replace the last line with the bellow line, but my output still says Hello, world Nikzad!, 3 where it should say Hello, world Nikzad!, 4.
run: echo Hello, world Nikzad!, 4
I found my problem. actually, when we are creating a new release, we are providing a tag name for that release, and when we create that tag name and push it to the repo, the version of the workflow at that point is what matters, so when I want to edit or update my workflow, I do the followings:
Edit the workflow (Make any change you want, eg change the title or add echo)
Commit and push workflow changes
Create a new tag and push
From the GitHub panel, create a new release based on the new tag
Now I see the action is running based on the new workflow
Note: Maybe it is more about learning of the process, but I did not find it straight forward anywhere, I hope it helps someone.
How to apply branches-ignore and paths-ignore on GitHub Actions? For example, if I have the following source tree:
|-src\
|----reports\
|-------<foo>DailyReports.ts
I want to only deploy that to production (master branch) but NOT staging (staging branch).
Any advice and insight is appreciated.
You won't be able to achieve what you want with ON trigger configuration alone. Therefore the implementation below wouldn't work as it would trigger for push to the specified path OR for push to the master branch, but not only for both:
on:
push:
path:
- 'src/reports/*DailyReports.ts'
branches:
- master
In that case, you could do it by using only one trigger at the workflow level, and check the other condition with an IF expression.
For example by doing this:
on:
push:
path:
- 'src/reports/*DailyReports.ts'
jobs:
job1:
runs-on: ...
if: github.ref == 'refs/heads/master' # run this job only for the master branch
steps:
...
Or by checking the branch at the workflow level, and then use something like this path-filter action to check if the file or directory has been updated or not before performing some operation.
I personally suggest the first option (cf example), as it's less verbose.
Note: If the src/reports/*DailyReports.ts path isn't working as expected, you can use the filter pattern cheat sheet to find the right expression.
I have a Github action in my repository that runs only when a specific file has changed. I have marked this action as required in repository settings so that whenever it fails the automatic merge gets blocked. Merge block is working fine but if a PR doesn't include a change to that specific file, Github still blocks the PR waiting for the job to complete which won't even run. Ideally, Github should ignore this action if it is not applicable.
I have put up a public repository that showcases this behavior. There are two PRs open: one that is working fine and the other one is blocked.
Any suggested workaround for this?
A workaround could be to update the workflow to run independently of the path, but check the path in the job execution with something like the path filter action, then return the message you want on the PR if the label isn't set and set an error to block the merge, or return that everything is ok if the file hasn't been updated.
Your workflow would in that case looks like below:
name: All Checked Verifier
on:
pull_request:
types: [labeled, unlabeled, opened, edited, synchronize]
jobs:
enforce-label:
runs-on: ubuntu-latest
steps:
- uses: dorny/paths-filter#v2
id: changes
with:
filters: |
public_api_views:
- '**/code.py'
- if: steps.changes.outputs.public_api_views == 'true'
uses: yogevbd/enforce-label-action#2.1.0
with:
REQUIRED_LABELS_ALL: "checked-everything"
REQUIRED_LABELS_ALL_DESCRIPTION: "Make sure we have checked everything and once done, add label 'checked-everything' to this PR."
It's weird because the https://github.com/sferhan/hello-github-actions/pull/6 not excuting the workflow
and i forked the repo https://github.com/bxb100/hello-github-actions, it's work fine... so i guess the action have problem.
In one of my repos (repo A), there is a script that gets the content of a file on another repo (repo B, not one of mine). Therefore, I would like to trigger a GitHub action on repo A each time there's a push on repo B. I didn't see this case on GitHub actions trigger documentation, is this possible?
You can execute each day a script with cron in order to start or not your workflow. A script can read easily the date of last commit of another repository.
Detect when the last commit is less than a day old
With this script, the exit code is 0, only if the last commit is less than a day old.
#!/bin/bash
exit $(curl -s https://api.github.com/repos/wikimedia/mediawiki/commits/REL1_36 | jq -r "((now - (.commit.author.date | fromdateiso8601) ) / (60*60*24) | trunc)")
Execute the script with cron each day
name: trigger
on:
schedule:
- cron: '30 5 * * *'
workflow_dispatch:
jobs:
check:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout#v2
- run: ./isUpdated.sh
Start your workflow when a new commit exists since yesterday
name: Your workflow
on:
workflow_run:
workflows: ["trigger"]
types: [completed]
workflow_dispatch:
jobs:
check:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- name: Checkout
uses: actions/checkout#v2
- run: echo ok
edit: this won't work since OP doesn't have push access to repo B
I think that you might be able to get what you want by using the repository_dispatch event. This essentially triggers the workflow when an endpoint is pinged with the correct payload.
From the documentation:
To trigger the custom repository_dispatch webhook event, you must send a POST request to a GitHub API endpoint and provide an event_type name to describe the activity type. To trigger a workflow run, you must also configure your workflow to use the repository_dispatch event.
My best guess is that your desired solution can be achieved by creating 2 workflows: 1 in Repo A that runs on: repository_dispatch, and 1 in Repo B that runs on: push and contains a step that hits Repo A's API (e.g. using curl). This would give you the following events:
You push to Repo B.
Repo B's on: push workflow is triggered, and the step that hits Repo A's API endpoint (e.g. using curl) is run.
Repo A's API endpoint receives the payload and the on: repository_dispatch workflow is triggered.
I'd like to integrate custom checks into some repos, but I can't figure out the best way to do this.
We have pretty large team of developers and we've introduced some naming conventions to maintain consistency in our repo. For example, every commit description should contain X, and every branch name should contain Y or Z, or have a match to some regular expression.
How do I enforce some custom checks on pull request, that branch that is being checked complies to these specified rules? Simply put, when pushed commits don't have Jira reference in their description - merge action is blocked. We also want to see these checks in the PR, like those CI checks which can pass or fail.
I've read about github apps, actions, api, marketplace and etc. Couldn't find something simple and straightforward.
What app or approach should I utilize for such a task?
The easiest way to do this is with a GitHub Action, which will allow you to execute whatever code you want to implement CI or linting checks.
You can create a shell script in your repository (for example, script/lint) that takes two arguments, the base branch and the branch being tested. Lint and check whatever you want, printing useful error messages and exiting zero if the commits are acceptable and nonzero if they're unacceptable.
Then create a workflow in .github/workflow/lint.yml with something like this (changing the script name if need be):
name: lint
on: pull_request
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- run: script/lint "$GITHUB_SHA" "$GITHUB_REF"
This will appear in the checks interface like other CI checks under the name “Lint.” You can customize the name field to change the name.
An example lint script that checks for JIRA tags in commit messages might look like this:
#!/bin/sh
RET=0
for i in $(git rev-list "$1".."$2")
do
printf "Checking $i for JIRA reference..."
if git log -1 --format="%B" $i | grep -qsE "[A-Z]+-[0-9]+"
then
echo "looks ok."
else
echo "failed."
RET=1
fi
done
exit $RET