I am trying to add a action to my github repo from the marketplace. Everytime I push I get an email that it fails and this is the only error I am getting:
{"message":"Bad credentials","documentation_url":"https://developer.github.com/v3"}
I tried going to the website they are refering to and I tried adding the "secrets.GITHUB_TOKEN" to my mail.yml like they tell me to and it doesn't seem to do anything.
main.yml:
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Run a one-line script
run: echo Hello, world!
- name: Run ESLint
uses: jinjubei/eslint-action#master #Touch
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
As Sujith mentioned in one of the comments above, your token has expired or is not set. You can read more about personal access tokens here.
Also, while the default GITHUB_TOKEN exposed to actions works for some actions, some actions require additional rights to run. I did not see the exact linter action you are using but found this one.
Its documentation states the following:
Important: Make sure to exclude the .github directory in your ESLint
and Prettier configs as the default GITHUB_TOKEN cannot be used to
update workflow files due to the missing workflow permission
Linking to the following docs: https://github.com/marketplace/actions/lint-action#limitations
I hope this helps.
NOTE: If you update your token and dependabot pull requests still fail, run #dependabot recreate to fix the workflow.
Related
I currently have a Github Actions workflow setup with the following trigger:
on:
pull_request:
paths:
- 'myFolder/*.yml'
I want this workflow to run on pull request events where a file matching with myfolder/*.yml has been changed. While this workflow does run on pull request events where this file has changed, it also runs on subsequent events even if they do not make any further changes.
The workflow this trigger is for runs a process using configuration from within the yml files and so if no changes happen to any of these files between commits (even if other files that do not match the filter are changed), the result will always be the same and does not need to be run.
I looked through the documentation for Github Actions and could not find anything that exactly matches my situation so would appreciate some help and pointers.
A simplified version with some name changes of the full workflow yml is:
name: Read yml files
on:
pull_request:
paths:
- 'myFolder/*.yml'
jobs:
promote:
runs-on: ubuntu-latest
name: Read files
steps:
- uses: actions/checkout#v2
with:
fetch-depth: 0
- name: Read
run: npm run read-yml
It's not possible to do on YML workflow level.
You can however detect your case and leave early from a workflow.
I can suggest using changed-files action:
- name: Get changed files
id: changed-files
uses: tj-actions/changed-files#v17.2
- name: List all added files
run: |
for file in ${{ steps.changed-files.outputs.added_files }}; do
echo "$file was added"
done
or you can use renamed_files, deleted_files if it fits better to your needs.
Then you can detect if there are any files that may trigger your generation action - if not, simply end the workflow.
I'm currently testing Github Actions workflows on this repository.
Context
I'm trying to use this workflow (1st):
on:
workflow_dispatch:
jobs:
job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- run: |
date > report.txt
git config user.name github-actions
git config user.email github-actions#github.com
git add .
git commit -m "generate or update report.txt file"
git push
To trigger this workflow (2nd):
on:
push:
paths:
- '**/report.txt'
pull_request:
paths:
- '**/report.txt'
jobs:
job:
runs-on: ubuntu-latest
steps:
- run: echo "Report .txt file has been updated"
What I tried
I followed the Github Action Documentation to implement the 2nd workflow with a Filter Pattern.
When I update the report.txt file locally, then commit and push the code to the repository, the 2nd workflow triggers.
However, I don't understand why the 2nd workflow doesn't trigger when the 1st workflow is completed, even with the report.txt file being updated on the default branch.
EDIT: I know I could trigger the 2nd workflow using others trigger event types (examples: repository_dispatch or workflow_run). But I'm trying to do it from a git push command on another workflow.
Question
Did I miss something on the 1st workflow to make it trigger the 2nd, or should I add something on the 2nd workflow to make it being triggered by the 1st one?
No, you didn't miss anything in your workflows.
You just need a different token.
When you use actions/checkout, it uses the GITHUB_TOKEN for authentication, and according to the documentation it doesn't trigger a new workflow run:
When you use the repository's GITHUB_TOKEN to perform tasks on behalf
of the GitHub Actions app, events triggered by the GITHUB_TOKEN will
not create a new workflow run. This prevents you from accidentally
creating recursive workflow runs.
To make it work, you need to generate a PAT (Personal Access Token), store it in your repository secrets, and use it in your checkout step:
- uses: actions/checkout#v2
with:
token: ${{ secrets.YOUR_PAT_TOKEN }}
There are three ways of authentication within a GitHub action.
1. GITHUB_TOKEN
The GITHUB_TOKEN is always available and implicitly defined by GitHub.
- uses: actions/checkout#v3
with:
token: ${{ secrets.GITHUB_TOKEN }}
It has limited permissions, though, as it cannot trigger new workflow runs. This is why your second workflow does not start.
2. PAT (Personal Access Token)
A personal access token can be generated in your developer settings. You can then add it as an encryped secret, e.g. PAT_TOKEN to the GitHub project and use it instead of the GITHUB_TOKEN:
- uses: actions/checkout#v3
with:
token: ${{ secrets.PAT_TOKEN }}
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.
Be aware that the personal access token has access to all of your repositories and hence can be a potential security risk.
3. Deploy key
You can generate a dedicated SSH keypair and add it to the repository as a Deploy Key. This is an alternative to the token-based authentication and has the same effect as the personal access token, but it only provides access to a single repository. It is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
After reading this answer:this
I tried to do the same.
I have a .net core project and in my case, I am using a repo with a publish version so my appsettings.json is in the root of the repo.
# This is a basic workflow to help you get started with Actions
name: DeployToStaging
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
FTP-Deploy-Action:
name: FTP-Deploy-Action
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2.1.0
with:
fetch-depth: 2
- uses: microsoft/variable-substitution#v1
with:
files: '${{env.DOTNET_ROOT}}/appsettings.json'
env:
ConnectionStrings.ToBudget: 'This is just a test'
- name: FTP Deploy
uses: SamKirkland/FTP-Deploy-Action#3.1.0
with:
ftp-server: <MyServer>
# FTP account username
ftp-username: <MyUsername>
ftp-password: ${{ secrets.FtpPassword }}
So basically I want to transform my connection string (for now it is just a test, in the future I will create a secret) and then push it to the server through FTP.
Everything is working except the variable substitution. The error is: No file matched with specific pattern: /appsettings.json
Any help would be much appreciated
Just found the issue.
instead of files: '${{env.DOTNET_ROOT}}/appsettings.json' I just need to do files: 'appsettings.json'
Now I am having a second issue. SamKirkland/FTP-Deploy-Action#3.1.0 doesn't like the change. It is avoiding uploading because the repo is dirty.
EDIT: regarding the second issue I moved to sebastionpopp/ftpaction
Can I trigger a new workflow from another workflow?
I'm trying to run a workflow after the first workflow has pushed a new release and it seems to ignore it.
Found the answer here:
An action in a workflow run can't trigger a new workflow run. For example, if an action pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
EDIT:
The quote above might be confusing. When I add a Personal Access Token (PAT) to the checkout action with repo permissions granted (and not repository's GITHUB_TOKEN), the following commands DO trigger other workflows:
- name: Checkout Repo
uses: actions/checkout#v2
with:
token: ${{ secrets.PAT_TOKEN }}
(In my case, running semnatic-release after this checkout, which creates a new release with a new tag - did trigger another workflow that runs only if a tag was created)
As described here, you can trigger another workflow using the workflow_run event.
For example we could think of two workflow definitions like this (the only prerequisite is, that both reside in the same repository - but I'am sure, there's also an event for other repos as well):
release.yml
name: CI release
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Release artifact
run: ...
do-something-different.yml
name: Do anything after the release of the first workflow
on:
workflow_run:
workflows: ["CI release"]
types:
- completed
jobs:
notify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Do something
run: ...
A crucial point here is that the name: CI release definition of the first yaml file must exactly match the workflow_run: workflows: ["CI release"] definition in the second yaml file. Another point is that this approach needs to be done on the default branch (which is mostly main or master) as the docs state:
Note: This event will only trigger a workflow run if the workflow file
is on the default branch.
If you don't want to use a general Personal Access Token (which has access to all of your repos), you can generate a dedicated SSH keypair for this purpose and add it to the repository as a Deploy Key. This is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- name: Checkout
uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.
Is it possible to reference another GitHub Action from my action.yml file?
Note, I'm talking about an action here, not a workflow. I know this can be done with workflows, but can actions reference other actions?
The answer seems to be: You can (now, Aug. 2021)
GitHub Actions: Reduce duplication with action composition
Previously, actions written in YAML could only use scripts.
Now, they can also reference other actions.
This makes it easy to reduce duplication in your workflows.
For example, the following action uses 3 actions to setup buildx, log in to Docker, and publish an image.
By combining these into a single action it provides a larger unit of reuse that you can put into the job of any workflow.
name: "Publish to Docker"
description: "Pushes built artifacts to Docker"
inputs:
registry_username:
description: “Username for image registry”
required: true
registry_password:
description: “Password for image registry”
required: true
runs:
using: "composite"
steps:
- uses: docker/setup-buildx-action#v1
- uses: docker/login-action#v1
with:
username: ${{inputs.registry_username}}
password: ${{inputs.registry_password}}
- uses: docker/build-push-action#v2
with:
context: .
push: true
tags: user/app:latest
Developers can then reference this action in all of their repositories as a single action:
on: [push]
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: my-org/publish-docker#v1
with:
registry_username: ${{secrets.REGISTRY_USERNAME}}
registry_password: ${{secrets.REGISTRY_PASSWORD}}
Learn more about action composition.
So, as described in "runs for composite actions":
runs.steps[*].uses
[Optional] 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.
We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number.
If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.
runs:
using: "composite"
steps:
# Reference a specific commit
- uses: actions/checkout#a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout#v2
# Reference a specific version
- uses: actions/checkout#v2.2.0
# Reference a branch
- uses: actions/checkout#main
# References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA
- uses: actions/aws/ec2#main
# References a local action
- uses: ./.github/actions/my-action
# References a docker public registry action
- uses: docker://gcr.io/cloud-builders/gradle
# Reference a docker image published on docker hub
- uses: docker://alpine:3.8
The answer seems to be: You can't.
However, I ended up internally downloading the different actions from NPM, and then re-using them within my own action.
Probably not a good idea in general, but this particular action I am making is designed to run on my own projects without requiring too much configuration, so that makes it more okay.
If both actions are nodejs actions you are serving over GitHub and you don't mind them reading the one set of input, this works pretty well:
npm install --save MyGitHubOrg/MyRepo#master
git add -f node_modules/ package.json package-lock.json
async function run() {
try {
require('my-action');
} catch (err) {
core.setFailed(`Failed to run habitat-action: ${err.message}`);
return;
}
// ...
}