I have a repository in GitHub and I want to create an Action to build a Docker image and push it to the DockerHub. I know how to do it but if I create the action in a branch other than master, GitHub does not run it.
This is a known problem (Workflow files only picked up from master?).
Any ideas to fix it?
According to the official GitHub Actions documentation (About workflow events):
The following steps occur to trigger a workflow run:
An event occurs on your repository, and the resulting event webhook has an associated commit SHA and Git ref.
The .github/workflows directory in your repository is searched for workflow files at the associated commit SHA or Git ref. The workflow files must be present in that commit SHA or Git ref to be considered.
For example, if the event occurred on a particular repository branch, then the workflow files must be present in the repository on that branch.
The workflow files for that commit SHA and Git ref are inspected, and a new workflow run is triggered for any workflows that have on: values that match the triggering event.
The workflow runs on your repository's code at the same commit SHA and Git ref that triggered the event. When a workflow runs, GitHub sets the GITHUB_SHA (commit SHA) and GITHUB_REF (Git ref) environment variables in the runner environment. For more information, see "Using environment variables."
Because of this, in order to test the workflows we need to perform a git action (ie. do push) in the created branch.
What has worked for me (through trial and error)
Create an empty YAML file in the .github/workflows folder
Create a PR to move that file to your branch
In your branch, you can now do the necessary edits to get your GH Action up & running. NOTE: next to updating your YAML, you also need to make a change
that actually triggers the workflow (I am using the below trigger, note the absence of the '.github' path trigger).
on:
push:
paths:
- 'path/to/your/code/**'
on:
push:
branches:
- "YOUR-TEST-BRANCH"
pull_request:
branches:
- "main"
paths:
- ".github/workflows/test.yaml"
Related
I'm new to Github action and want to trigger the master branch .github/workflows present in the base branch repo whenever the new PR is created.
Current Code:
on: pull_request: branches: - "**"
Its trigger the workflow code present in head branch and not able to fetch the secret key present in the base branch repo when PR is create from another repo.
I want to trigger the specific branch workflow for every PR created to that repo.
The pull-request trigger for an action runs in the context of the merge commit between the head branch and the base branch. The pull_request_target trigger runs in the context of the base branch of the pull request. That seems like what you want for this action.
However, I should note that a branch on the git repo is probably not the place to store a "Secret key", take a look at Github's secrets feature for securely storing keys for use in actions workflows.
I have a mono repo project on GitHub which looks like this:
main_directory/apps/app_A
main_directory/apps/app_B
To create builds for app_A, I have a GitHub action which is configured as follows:
// build_app_A.yml
name: Build App A
on:
push:
paths:
- "apps/app_A/**"
- ".github/workflows/build_app_A.yml"
workflow_dispatch:
inputs:
ref:
description: "Git reference (commit, branch, or tag) to build"
required: true
default: "main"
...
Adding the on -> push -> paths thing makes sure that this GitHub action runs only when files inside the app_A subdirectory change, or when this workflow file itself changes.
This works fine. But there is a problem which is making it run redundantly.
Say I have a PR for app_B and this pull request has changes only inside the apps/app_B folder.
This pull request became stale and I decide to rebase it on top of the main/master branch. The main/master branch has commits related to app_A and my app_B PR is behind these commits.
Now when I rebase this PR's branch and push it, even though the resulting diff has no changes related to app_A compared to the main/master branch, this GitHub action still runs.
My assumption was that given the paths inside my action, the action will run only when the git diff shown on GitHub has changes inside the specified paths, but this doesn't seem to be the case.
What am I missing here? Is there a way I can avoid these redundant builds?
I am able to run workflows on GitHub fine. But I don't want my git history to contain anything unrelated to the development of the software, and nothing specific to any one code hosting site, e.g., GitHub. Basically I don't want to add and track .github/workflows/ in my git repo.
Thinking it would work, I created a separate branch, gh-actions, and added the .github/workflows/main.yml there.
on:
workflow_dispatch:
push:
branches:
- master
pull_request:
branches: [ master ]
jobs:
<snip>
But apparently this workflow won't even be registered by GH. So I added gh-actions branch to on: push: branches. After pushing this branch to GH, the workflow was registered (checked with gh workflow list).
Now I went to run it on the default branch and got error.
$ gh workflow run .github/workflows/main.yml --ref master
could not create workflow dispatch event: HTTP 422: Workflow does not have 'workflow_dispatch' trigger (https://api.github.com/repos/3N4N/TwitchRecover/actions/workflows/14900813/dispatches)
Apparently workflow_dispatch event only works if it's in the default branch.
I'm now out of ideas. One final way is to change the default branch to gh-actions so that the workflow can be run on master branch, but that would mean that cloning this repository would by default clone the gh-actions branch, and I would rather not deal with that.
If anyone else has any idea, I'd be glad to try it.
I saw a lot of uses of :
jobs:
myjob:
steps:
- name: checkout
uses: "actions/checkout#something"
- ...
But i can not find what is the purpose of the line :
uses : "actions/checkout#something"
Is it similar to this ?
run: git checkout something
For this line: uses : "actions/checkout#something", it will use the actions/checkout github action (source here) with the ref something. This ref only refers to the github action version (nothing to do with your repo)
The uses statement refers to a github action that is being used in this step. From github documentation for jobs.<job_id>.steps[*].uses:
Selects an action to run as part of a step
in your job. An action is a reusable unit of code. You can use an
action defined in the same repository as the workflow, a public
repository, or in a published Docker container image.
From actions/checkout readme :
This action checks-out your repository under $GITHUB_WORKSPACE, so your workflow can access it.
By default it checks out only one commit. My understanding is that it's doing something similar to:
git fetch --depth 1 origin $GITHUB_REF
This action also persists an auth token in git config. This way, your workflow can run authenticated git commands
By default, it clones your current repository ({{ github.repository }}) but you can also use this action to clone a different repository, and specify additionnal parameters like token, branch, path etc...
An example with additionnal input parameters: check out all git history by setting fetch-depth to 0 (default is 1), see usage doc:
- uses: actions/checkout#v2
with:
fetch-depth: 0
Understanding terminologies made things clearer
Remote repo - It can also be referred to as the origin
Origin - the default name of the remote repo or the source repo being cloned
Head - a reference to human-friendly names for branches
git checkout - switch to a particular branch and displaying the changes currently on that branch
origin/name_of_branch - branch name created when fetching changes from a particular branch on the remote repo
Side Note: When git fetch is used, a custom branch is created locally in the form "origin/name_of_branch", changes on this branch can be viewed locally. These changes are the updated version of the files, not the specific change in that file as seen when commits are being inspected on GitHub.
Back to the question
When the action is executed
jobs:
myjob:
steps:
- name: checkout
uses: "actions/checkout#something"
- ...
The default steps being executed are:
The current repo in which the workflow is being triggered gets cloned.
Depending on the defined events such as a push or pull request:
For a push event, it runs the command below, where $GITHUB_REF points to the latest commit on the specified branch for the push event in the workflow.
git fetch --depth 1 $GITHUB_REF
For pull requests, it checks $GITHUB_REF points to the latest commit on the pull request source branch. This means it points to the would-be code/result from merging the pull request. This is the code/result other steps within the job are executed on such as running builds or tests. (Not completely sure of the command which runs under the hood)
Environment variables being referenced in the commands are explained here.
Additional options can be added to implement specific processes or scenarios such as checking out a different branch. This can be found in the official repo readme.
I have created on my main branch with
on:
push:
branches: [ test ]
I have noticed, that while I can trigger it manually, and it will work, it will not actually trigger if I push to test. For that, I needed to create that same action file on test. Now, it seems like I don't even need to have the action on the main branch, is that correct?
So why does even the option so specify the branch that it should trigger on exist? It only triggers on the branches the file exists anyway. That said, I found it frustrating that I have to merge my one file from main to my test branch, is there a way to trigger the action automatically on push even if I do not have it on my test branch, only on main?
No, it's not possible. The order of operations in a workflow run triggered by push or pull request is described in the reference documentation:
An event occurs on your repository. The event has an associated commit SHA and Git ref.
GitHub searches the .github/workflows directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event.
A workflow run is triggered for any workflows that have on: values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run.