GitHub - jobs : what is : use actions/checkout - github

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.

Related

Why is Github pulling in commits for my entire branch's history for my new Github Tag?

I am currently trying to implement an automated release GHA. One of the main features is that it will generate release notes based on previous tags. For some reason every time I generate release notes, Github will populate the release notes with every single branch that has been merged into the branch that I am creating release notes for. It should only be creating release notes for branches that have been merged between tags.
For example, I'm upgrading my repo's version from tag v1.1 to tag v1.2
When generating release notes it will pull in every merge from the branch I am adding a tag to since the beginning of the entire repo. Instead it should only pull in merges since v1.1
I think this might have to do with the fact that my tags aren't properly attached to branches. I am using this command in my GHA action script to get my previous tag.
git describe --tags --abbrev=0
This returns:
fatal: No tags can describe 'ExampleGitSHA'
It seems that GitHub is not recognizing my previous tags for whatever reason.
Following actions/checkout issue 701, check if your git describe --tags --abbrev=0 fails because your GitHub Action did not fetch any tag.
If that is the case, add a step after the actions/checkout:
- name: Checkout
uses: actions/checkout#v3
- name: Get tags
run: git fetch --tags origin

Github Actions Error on "Run google-github-actions/setup-gcloud#master" . How to resolve this?

I am using Github actions to deploy my application to Google cloud and it gave me following error -
Run google-github-actions/setup-gcloud#master
Warning: google-github-actions/setup-gcloud is pinned at "master". We strongly advise against pinning to "#master" as it may be unstable. Please update your GitHub Action YAML from:
uses: 'google-github-actions/setup-gcloud#master'
to:
uses: 'google-github-actions/setup-gcloud#v0'
Alternatively, you can pin to any git tag or git SHA in the repository.
Error: On 2022-04-05, the default branch will be renamed from "master" to "main". Your action is currently pinned to "#master". Even though GitHub creates redirects for renamed branches, testing found that this rename breaks existing GitHub Actions workflows that are pinned to the old branch name.
That 3rd party action is moving away from the convention of using a branch named master.
Instead of:
uses: google-github-actions/setup-gcloud#master
Change the reference in your YAML to:
uses: google-github-actions/setup-gcloud#v0

Forking actions/checkout#v2 at organization level to be used repo's github actions

Problem:
Inherently, github actions has no information about the code within the repo it's being run in. To rid that problem, there is the actions/checkout workflow that is the defacto start of most workflows.
Our enterprise account got locked down to only local actions only:
Because of this, we are not able to use the actions/checkout#v2 at the start of our workflow, thus rendering our Github Actions useless.
Proposed Solution
Fork the actions/checkout repo as a submodule of a repo and use that reference in my code like so:
steps:
- uses: <enterprise_name>/<repo_name>/checkout#main
When running this action as a test, I get this error message:
Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/_actions/<enterprise_name>/<repo_name>/main/checkout'.
Did you forget to run actions/checkout before running your local action?
So my question:
Is there a way to run a forked or local version of actions/checkout? The above example is telling me, I can't run a local version of actions/checkout because I have clone the repo which is ironic error.
You need to push the actions/checkout repo into an internal or public repo on your enterprise. Then update your workflow to reference organization/repo#2 instead.
After forking the actions/checkout repo to my jessehouwing-actions this would result in the following update of the YAML:
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout#v3
Would become:
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: jessehouwing-actions/checkout#v3
Don't use submodules.

Is it possible to update files as part of a merge via GitHub Actions without creating a second commit?

Currently, I'm trying to automate the bump versions for the applications as part of the PR Merge using the GitHub Actions. There is a custom script that would identify the current version of the application and the label attached with the PR and bump the major|minor|patch version accordingly on the file where the version numbers are stored. It is important that the version bump happens only at the time when PR is merged and as part of GitHub Actions because it helps in avoiding the merge conflict in the version file and takes away the manual way of bumping the version.
The GitHub Actions code snippet is given below.
jobs:
release:
# Skip on Pull Request Close event.
if: "!(github.event_name == 'pull_request' && !github.event.pull_request.merged)"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
ref: ${{ github.ref }}
- id: bumpversion
if: github.event.pull_request.merged
env:
PR_LABELS: ${{ toJson(github.event.pull_request.labels) }}
run: bash .github/scripts/bump_version.sh -l "${PR_LABELS}"
The bump_version.sh script has a function given below that makes the version changes and then pushes them to the main branch.
git config user.email "${GITHUB_ACTOR}#users.noreply.github.com"
echo "commiting the version bump changes..."
git add .
git commit -m "Bump Version v${current_version} -> v${incremented_version}"
echo "pushing the version bump changes..."
git push origin dev
This runs fine but the problem is that it makes 2 commits on the main branch when a PR is merged to it. There is a CI/CD pipeline that listens to this main branch for changes and it gets triggered when there is a new commit to it. Since this PR merge makes 2 commits, it is triggered twice.
2 commits for single PR merge image
The question: Is it possible to update files as part of a merge via GitHub Actions without creating a second commit? Is there any other way to achieve a solution to this problem that will help me to bump the version as part of the PR Merge?
My immediate thought is that you could alter the trigger ("on:") in CI/CD to ignore the first of the 2 commits, and only run CI/CD on the second one.
There's a number of ways you could do that, utilizing any of the metadata that comes with a commit. Here's an idea that utilizes the tag. You'd have to refactor the code that defines incremented_version probably, but shouldn't be hard to do in bash.
Here's a CI/CD that would ignore something tagged *.0.0, but would trigger on anything like *.1 or *.0.1:
on:
push:
# Sequence of patterns matched against refs/tags
tags:
- !v*.0.0
- !v*.0 # Do not push events to tags v1.0.0, v1.0, v2.0.0, and v2.0, etc.
Personally I like the idea of making the 1st of the 2 commits have an extra .0 and ignoring those. It seems cleaner. After configuring the bash script to do that,:
on:
push:
# Sequence of patterns matched against refs/tags
tags:
- !v*.0.0 # Do not push events to tags v1.0.0, v2.0.0, etc.

How to run a GitHub Action from a branch other than master?

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"