I don't quite understand the extent to which Github actions/cache works, what I mean:
Caching works fine if I make a pull request and then in the same pull request I add 1 more commit, but if I create a new pull request in the same branch - the caching is reset and starts again, but why?
Is there any way to extend file caching to all yml files and so that each pull request uses existing caching?
Because to speed up the work it turns out - that developers always need to pour their work into one branch, and it somehow sounds like some nonsense.
Info
My caching key is formed as follows
- uses: actions/cache#v2
id: composer-cache
with:
path: .github/docker/development/php-cli/composer/cache
key: ${{ runner.os }}-develop-composer-${{ hashFiles('src/composer.lock') }}
restore-keys: |
${{ runner.os }}-develop-composer-
Yeah, GitHub's cache action has unintuitive behavior across branches. Pull request workflows don't share, and tag workflows never get a cache hit.
Per the docs (useful bit made bold):
A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually main). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch feature-b has the base branch feature-a, a workflow triggered on feature-b would have access to caches created in the default branch (main), feature-a, and feature-b.
So the solution then is to make a separate workflow triggered by pushes to main — plus any base branches you like — just to keep a fresh cache available to pull requests and tags.
Related
In our github organization we have a lot of repositories. All of them shall convert JIRA tickets names in comments/PRs like XYZ-123 to links to the corresponding JIRA ticket. This is possible with Autolinking.
The downside of this approach ist, that Autolinking is supporting only Prefixes (no regex-es like GitLab). This results in one entry per JIRA projekt (i.e if I want to support ABC-123 and XYZ-123 two entries with the prefix ABC- and XYZ- are required).
What makes things worse is, that Autolinking has to be configured per repository. This means I have to add all Autolink entries to every Repository in our company (and maintain these lists).
Is there no simpler solution?
There does not seem to be any native simpler solution than the official Configuring autolinks to reference external resources.
You would need a GitHub Action to update a PR, replacing/making the JIRA links as you want them to be.
Example, with a .github/workflows/pr_update.yml:
name: PR update
on:
pull_request:
types: [opened]
jobs:
update_pr:
name: Update PR
runs-on: ubuntu-latest
steps:
- uses: tzkhan/pr-update-action#v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
base-branch-regex: '[A-Za-z\d-_.\\/]+'
head-branch-regex: '^([A-Za-z])+-\d+'
title-template: '%headbranch%: '
body-template: |
Jira issue: %headbranch%
---
body-update-action: 'prefix'
body-uppercase-base-match: false
I have workflow that is triggered when a specific file is changed. Is it possible to ensure that this workflow is only triggered the first time that file is changed?
The use case is:
a repository is created from a template repository
to initialize the README and other things in the repo, some variables can be set in a JSON config file
once that file is committed, the workflow runs, creates the README from a template etc.
I have tried to do let the workflow delete itself before it commits and pushes the changed files. That doesn't work: fatal: not in a git directory and fatal: unsafe repository ('/github/workspace' is owned by someone else).
What might work is adding a topic like initialized to the repo at the end of the workflow and check for the presence of this topic at the beginning of the workflow. However, this is feels like a hack in that I'm abusing topics for something they're probably not meant to do.
So my question remains: is there a good way to only run the workflow once?
With the help of the comment by frennky I managed to do solve this by using the GitHub CLI to disable the workflow.
Here is the step at the end of the workflow that does this:
- name: Disable this workflow
shell: bash
run: |
gh workflow disable -R $GITHUB_REPOSITORY "${{ github.workflow }}"
env:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
When I use in my workflow github.ref_name it doesn't provide me a branch name from where I triggered this workflow. I get 16/merge. Why? When I use github.ref_type I clearly see that my ref type is branch so why I don't get branch name?
Also it's showing when I use $GITHUB_REF or git symbolic-ref HEAD (and separating refs/heads/ off). Ah and I tried github.event.push.ref but it's not showing me anything.
How to get always branch name from where I triggered the workflow?
For following code:
Run echo running on branch ${GITHUB_REF##*/} ${GITHUB_REF}
When your workflow runs becuase of push event you will get:
running on branch main refs/heads/main
But for pulr request event it would be:
running on branch merge refs/pull/3/merge
Why's that?
If the repository is on GitHub and you have any Pull Requests that have been opened, you’ll get these references that are prefixed with refs/pull/. These are basically branches, but since they’re not under refs/heads/ you don’t get them normally when you clone or fetch from the server — the process of fetching ignores them normally.
You can also check this question here
I have a set of GitHub Actions configured to block pull requests from being merged until the Actions complete successfully. However, every time a new commit is pushed to a PR, the Actions are run again, which can be very wasteful if the author is not yet ready to merge, and intends to make future changes. Is there any way to have a GitHub Action still block a PR being merged but also not run the Action automatically?
With this recent update you can now convert pull requests back to draft status. So you could do that when you need to make changes and disable the CI for drafts. Then convert the draft to a pull request after the changes are complete to rerun CI.
on: pull_request
jobs:
build:
if: github.event.pull_request.draft == 'false'
runs-on: ubuntu-latest
steps:
...
One workaroound would be for the Action to look for a specific comment (for example: "[TO MERGE]: this commit is about ...), and:
return immediately if '[TO MERGE]' is not found, minimizing the action overhead on each commit
go on with checks, if '[TO MERGE]' is found.
I have a workflow that FTPs files by using an external action from someuser:
- name: ftp deploy
uses: someuser/ftp-action#master
with:
config: ${{ secrets.FTP_CONFIG }}
Is this a security concern? For example could someuser change ftp-action#master to access my secrets.FTP_CONFIG? Should I copy/paste their action into my workflow instead?
If you use ftp-action#master then every time your workflow runs it will fetch the master branch of the action and build it. So yes, I believe it would be possible for the owner to change the code to capture secrets and send them to an external server under their control.
What you can do to avoid this is use a specific version of the action and review their code. You can use a commit hash to refer to the exact version you want, such as ftp-action#efa82c9e876708f2fedf821563680e2058330de3. You could use a tag if it has release tags. e.g. ftp-action#v1.0.0
Although, this is maybe not as secure because tags can be changed.
Alternatively, and probably the most secure, is to fork the action repository and reference your own copy of it. my-fork/ftp-action#master.
The GitHub help page does mention:
Anyone with write access to a repository can read and use secrets.
If someuser does not have write access to the repository, there should be no security issue.
As commented below, you should specify the exact commit of the workflow you are using, in order to make sure it does not change its behavior without your knowledge.