How to test a custom GitHub action without publishing it to marketplace?
Similar question to ^ - I'm trying to test a GHA in a different public repository without publishing it.
This solution doesnt work for me
steps:
- uses: <username>/<repo-name>#<branch-name>
with:
# input params if there is any
I get this error when running my GHA
line 1: <actualUserName>/<actual-repo-name>#main: No such file or directory
Error: Process completed with exit code 127.
Do I need to provide a specific URL to the repo?
Related
I'm not sure if this is a bug or a breaking change happened as of yesterday, I have a pretty simple setup calling three reusable workflows:
name: pr-checks
on:
pull_request:
branches: "**"
jobs:
lint:
name: Call Lint
uses: ./.github/checks/check-lint.yaml
test:
name: Call Test
uses: ./.github/checks/check-test.yaml
e2e:
name: Call E2E
uses: ./.github/checks/check-e2e.yaml
But this throws
"invalid value workflow reference: no version specified"
as of now, even though identical workflows have worked yesterday.
When reusing workflows like this at the 'job' level - it is not necessary to specify version, in fact, it used to error out if I specified the version.
Screenshots attached as I think this doesn't make much sense.
I did click on 're-run all jobs and it re-ran successfully.
However, without any discenrable difference and after also removing the build step just to be sure there's nothing weird happening there:
As you can see in your 2 screenshots, one is referring to the .github/workflows directory (the one which worked), and the other to the .github/checks directory (the one which didn't).
Short answer: If you change the workflow folder back to workflows instead of checks, it should work as expected.
Long answer: It seems there is a confusion between the syntax of two different concepts:
local actions (using an action in the same repo)
reusable workflows (reusing the same workflow in different workflows)
LOCAL ACTIONS
To access local actions (folders with action.yml file) from your workflow, you need to use the actions/checkout first, to allow it to access the other repository folders and files.
Example:
steps:
- uses: actions/checkout#v3 # Necessary to access local action
- name: Local Action Call
uses: ./.github/actions/local-action #path/to/action
I've made a POC here some time ago if you want to have a look.
REUSABLE WORKFLOWS
Now, if you want to use reusable workflows, the issue is different:
As with other workflow files, you locate reusable workflows in the
.github/workflows directory of a repository. Subdirectories of the
workflows directory are not supported.
GitHub documentation reference
In that case, according to this other section from the documentation:
You reference reusable workflow files using one of the following
syntaxes:
{owner}/{repo}/.github/workflows/{filename}#{ref} for reusable
workflows in public repositories.
./.github/workflows/{filename} for reusable workflows in the same repository.
{ref} can be a SHA, a release tag, or a branch name.
Example:
lint:
name: Call Lint
uses: ./.github/workflows/check-lint.yaml#{SHA/TAG/BRANCH}
or
lint:
name: Call Lint
uses: ./.github/workflows/check-lint.yaml
Here is another POC for the workflow call using this reusable workflow
CONCLUSION
It's like you were trying to call a reusable workflow as if it was a local action, which won't work as reusable workflows need to be located in the .github/workflows directory.
Note that you could eventually add the #branch-name at the end of the workflow call to be sure to use the workflow from the branch you want to test if the reusable workflow is already present on the default branch.
I'm developing a static site using John Sundell's Publish framework. I've got the site mostly working, and I want to deploy it to my GitHub Pages repo. Publish includes a publishing step called .deploy(using: .gitHub("githubusername/githubusername.github.io", useSSH: false)) (to be clear, I did use my actual username). However, when I ran it the first time I received a pop-up authentication window, which I entered and it said incorrect password. Since then, whenever I run it, it just shows an error and doesn't offer any password window:
publish deploy
Fatal error: Error raised at top level: Publish encountered an error:
[step] Deploy using Git (https://github.com/githubusername/githubusername.github.io.git)
[path] GitDeploy
[info] Failed to create folder: file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-1103.8.25.8/swift/stdlib/public/core/ErrorType.swift, line 200
/bin/bash: line 1: 9577 Illegal instruction: 4 swift run RyanBudishSite --deploy
❌ ShellOut encountered an error
Status code: 132
Message: "Fatal error: Error raised at top level: Publish encountered an error:
[step] Deploy using Git (https://github.com/githubusername/githubusername.github.io.git)
[path] GitDeploy
[info] Failed to create folder: file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-1103.8.25.8/swift/stdlib/public/core/ErrorType.swift, line 200
/bin/bash: line 1: 9577 Illegal instruction: 4 swift run RyanBudishSite --deploy"
Output: ""
Does anyone have any experience getting Publish to deploy to GitHub Pages? Any tips/ideas/suggestions would be very useful
I have deployed my site in GutHub Pages using the built in .gitHub publishing step.
To deploy to GitHub Pages, Publish clones your githubusername/githubusername.github.io project into <YourProjcet>/.publish/GitDeploy. I am new to Swift and Publish, but by the looks of your error, it was unable to create the GitDeploy folder or clone your pages project there.
Run deploy once, after it fails go to the above location and see what is wrong. If there's some issue with pushing/fetching the GitHub Pages repo, resolve it manually and try running the publish deploy again.
If GitDeploy folder is not created, maybe creating one manually will fix it.
I have been trying to integrate Google Cloud Build with my GitHub account. I have set up working build triggers in the past for other projects on GCP - but with this one, I just can't get it to work reliably. Here is what I did:
Install the Google Cloud Build App on GitHub and link it to my Google Cloud Account.
Connected to my GitHub repository in Google Cloud Build. As source, I selected "GitHub (Cloud Build GitHub App)".
Let Cloud Build create its default trigger for me - just to make sure that the settings are correct.
Now, when manually running the default trigger, I always receive the following error message after selecting my branch: "Failed to trigger build: Request contains an invalid argument." Here is what that looks like:
The trigger also does not work when invoked through a new commit in the GitHub repository. There are two different errors I have spotted through the GitHub UI:
The GitHub Cloud Build Action essentially reports the same error as Cloud Build itself when manually invoking the build and immediately fails:
The GitHub Cloud Build Action is queued/started, but never actually does anything. In this case, Cloud Build does not even seem to know about the build that was triggered by GitHub. The action will remain in this state for hours, even though Cloud Build should usually cancel builds after 10 minutes by default.
Here are some things that I've tried so far to mitigate the issue:
Create all sorts of different trigger variations - none of them seems to work. The error is always the same.
Uninstall the Cloud Build App on Github, unlink my Google Cloud account, and go through the entire setup process again.
When connecting the repository in Cloud Build, instead of selecting the GitHub App as a source, select "GitHub (mirrored)".
At this point, I seem to be stuck and I would be super grateful for any advice/tip that could somehow push me in the right direction.
One more thing that I should note: I have had the triggers working for a while in this project. They stopped working some time after I renamed my master branch on GitHub to "production". I don't know if that has anything to do with my triggers failing though.
I found that this can be caused when you have an "invalid" CloudBuild config file (e.g. cloudbuild.yaml).
This threw me off, because it doesn't necessarily mean it is invalid YAML or JSON, just that it is not what CloudBuild expects.
In my case, I defined a secretEnv value, but had removed the step that utilized it. Apparently, CloudBuild does not allow secretEnv values to go unused, which resulted in the cryptic error message:
Failed to trigger build: Request contains an invalid argument.
In case that isn't clear, here is an example of a config file that will fail:
steps:
- name: "gcr.io/cloud-builders/docker"
entrypoint: "bash"
args: ["-c", "docker login --username=user-name --password=$$PASSWORD"]
secretEnv: ["PASSWORD"]
secrets:
- kmsKeyName: projects/project-id/locations/global/keyRings/keyring-name/cryptoKeys/key-name
secretEnv:
PASSWORD: "encrypted-password"
UNUSED_PASSWORD: "another-encrypted-password"
UNUSED_PASSWORD is never actually used anywhere, so this will fail.
Since this error message is so vague, I assume there are other scenarios that could cause this same problem, so take this as just an example of the type of mistakes to look for.
I just got a GitHub account and writing small scripts in Python which I am learning.
While adding my code to GitHub I noticed there is an option to run tests/validation on my code but mine is empty.
I googled around and found that lint and black and are good checks.
I found this Action that I want to add - https://github.com/marketplace/actions/python-quality-and-format-checker
There is a "script" and a "config" that I think I need to add/update somewhere. Also when I click "Use latest version" it tells me to add the code into some .yml.
Can anyone assist me in installing this Action or point me in the right direction? Also, how can I use this Action on all my repositories/code?
=======================================
EDIT:
This link has the instructions - https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow
place yaml or yml in this directory -> .github/workflows
For this Action: https://github.com/marketplace/actions/python-quality-and-format-checker
the code inside the file will look like this:
on: [push, pull_request]
name: Python Linting
jobs:
PythonLinting:
name: Python linting
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Konstruktoid Python linting
uses: konstruktoid/action-pylint#master
thanks to: bertrand martel
pylint is part of the new GitHub Super Linter (github/super-linter):
Introducing GitHub Super Linter: one linter to rule them all
The Super Linter is a source code repository that is packaged into a Docker container and called by GitHub Actions. This allows for any repository on GitHub.com to call the Super Linter and start utilizing its benefits.
When you’ve set your repository to start running this action, any time you open a pull request, it will start linting the code case and return via the Status API.
It will let you know if any of your code changes passed successfully, or if any errors were detected, where they are, and what they are.
This then allows the developer to go back to their branch, fix any issues, and create a new push to the open pull request.
At that point, the Super Linter will run again and validate the updated code and repeat the process.
And you can set it up to only int new files if you want.
Update August 2020:
github/super-linter issue 226 has been closed with PR 593:
This Pr will add:
Black python linting
Updated tests
I currently have TravisCI building on PRs in a public GitHub repo.
The instructions for Coveralls say to put this in a .coveralls.yml file:
service_name: travis-pro
repo_token: <my_token>
That doesn't work for me because the .coveralls.yml file would be public--checked into GitHub. My TravisCI is integrated into my GitHub repo wired to a branch and fires on PR.
So I tried this:
In TravisCI's site I set an environment var:
COVERALLS_REPO_TOKEN to my token's value.
Then modded my .travis.yml to look like this:
language: scala
scala:
- 2.11.7
notifications:
email:
recipients:
- me#my_email.com
jdk:
- oraclejdk8
script: "sbt clean coverage test"
after_success: "sbt coverageReport coveralls"
script:
- sbt clean coverage test coverageReport &&
sbt coverageAggregate
after_success:
- sbt coveralls
Now when I create a PR on the branch this runs ok--no errors and I see output in Travis' console that the coverage test ran and generated files. But when I go to Coveralls I see nothing--"There have been no builds for this repo."
How can I set this up?
EDIT: I also tried creating a .coveralls.yml with just service_name: travis-ci
No dice, sadly.
How can I set this up?
Step 1 - Enable Coveralls
The first thing to do is to enable Coveralls for your repository.
You can do that on their website http://coveralls.io:
go to http://coveralls.io
sign in with your GitHub credentials
click on "Repositories", then "Add Repo"
if the repo isn't listed, yet, then "Sync GitHub Repos"
finally, flip the "enable coveralls" switch to "On"
Step 2 - Setup Travis-CI to push the coverage infos to Coveralls
You .travis.yml file contains multiple entries of the script and after_success sections. So, let's clean that up a bit:
language: scala
scala: 2.11.7
jdk: oraclejdk8
script: "sbt clean coverage test"
after_success: "sbt coveralls"
notifications:
email:
recipients:
- me#my_email.com
Now, when you push, the commands in the script sections are executed.
This is were your coverage data is generated.
When the commands finish successfully the after_success section is executed.
This is were the coverage data is pushed to coveralls.
The .coveralls config file
The .coveralls file is only needed to:
public Travis-CI repos do not need this config file since Coveralls can get the information via their API (via access token exchange)
the repo_token (found on the repo page on Coveralls) is only needed for private repos and should be kept secret. If you publish it, then anyone could submit some coverage data for your repo.
Boils down to: you need the file only in two cases:
to specify a custom location to the files containing the coverage data
or when you are using Travis-Pro and private repositories. Then you have to configure "travis-pro" and add the token:
service_name: travis-pro
repo_token: ...
I thought it might be helpful to explain how to set this up for PHP, given that the question applies essentially to any language that Coveralls supports (and not just Lua).
The process is particularly elusive for PHP because the PHP link on Travis-CI's website points to a password-protected page on Coveralls' site that provides no means by which to login using GitHub, unlike the main Coveralls site.
Equally confusing is that the primary PHP page on Coveralls' site seems to contain overly-complicated instructions that require yet another library called atoum/atoum (which looks to be defunct) and are anything but complete.
What ended-up working perfectly for me is https://github.com/php-coveralls/php-coveralls/ . The documentation is very thorough, but it boils-down to this:
Enable Coveralls for your repository (see Step 1 in the Accepted Answer).
Ensure that xdebug is installed and enabled in PHP within your Travis-CI build environment (it should be by default), which is required for code-coverage support in PHPUnit.
Add phpunit and the php-coveralls libraries to the project with Composer:
composer require phpunit/phpunit php-coveralls/php-coveralls
Update travis.yml at the root of the project to include the following directives:
script:
- mkdir -p build/logs
- vendor/bin/phpunit tests --coverage-clover build/logs/clover.xml
after_success:
- travis_retry php vendor/bin/php-coveralls
Create .coveralls.yml at the root of the project and populate it with:
service_name: travis-ci
I'm not positive that this step is necessary for public repositories (the Accepted Answer implies that it's not), but the php-coveralls documentation says of this directive (emphasis mine):
service_name: Allows you to specify where Coveralls should look to find additional information about your builds. This can be any string, but using travis-ci or travis-pro will allow Coveralls to fetch branch data, comment on pull requests, and more.
Push the above changes to the remote repository on GitHub and trigger a Travis-CI build (if you don't already have hooks to make it happen automatically).
Slap a Coveralls code-coverage badge in your README (or wherever else you'd like). The required markup may be found on the Coveralls page for the repository in question, in the Badge column.