actions / checkout Goto Github PK
View Code? Open in Web Editor NEWAction for checking out a repo
Home Page: https://github.com/features/actions
License: MIT License
Action for checking out a repo
Home Page: https://github.com/features/actions
License: MIT License
As per issue #14, the standard way to make private submodules work with checkout is to use insteadOf to rewrite git@ urls to https:// and to use a private access token, e.g.:
- name: Fix submodules
run: echo -e '[url "https://github.com/"]\n insteadOf = "[email protected]:"' >> ~/.gitconfig
- name: Checkout server
uses: actions/checkout@v1
with:
fetch-depth: 1
submodules: true
token: ${{ secrets.CUREATR_PAT }}
As of a few days ago, checkout@v1 now seems to overwrite ~/.gitconfig and this no longer works.
It appears this PR made the change #56
How should we make private submodules work with the non-backward compatible checkout@v1?
Also where is the source code to the checkout plugin, it would be useful for debugging breaking changes like this.
I just spent the better part of an hour debugging a failing workflow, and it turned out the root cause was that the project's submodules had not been checked out recursively.
I had configured the checkout with:
- uses: actions/checkout@v1
with:
submodules: true
I had inferred the true
value for the submodules
input from the action's documentation, which described the input as "Whether to recursively clone submodules; defaults to false". It turns out, setting the value to true
checks out submodules, but not recursively. After searching through the closed issues, I discovered that for recursive checkout of submodules, the value needs to be recursive
.
It would be very helpful if the action documentation could be updated to correctly indicate what value needs to be passed to get the documented behavior.
👋 Actions team,
I think it's great that we publish the description for each of the inputs for this action in the action.yml
file: https://github.com/actions/checkout/blob/master/action.yml
One opportunity I see here is to publish them in the README. This would be very helpful for any user leveraging this Action and make them aware that such inputs exist, especially those who leverage accompanying features (submodules, LFS, and so forth).
Would the team be open to contributions for updating the README file to include these inputs? In this way, consumers don't need to worry about "digging in the code" and can just get all the information they need up front in the documentation.
Thanks for hearing me out! 🙇
Upon attempting to set the checkout path
Lines 19 to 20 in af513c7
The following error was emitted:
Your workflow file was invalid: .github/workflows/build.yml (Line: 22, Col: 7): Unexpected value 'path'
My action file
name: Build & Deploy
on: [push]
jobs:
build:
name: Build & Deploy
runs-on: ubuntu-latest
strategy:
matrix:
go-version: [ '1.12' ]
steps:
- name: Use go ${{ matrix.go-version }}
uses: actions/setup-go@v1
with:
version: ${{ matrix.go-version }}
id: go
- name: Checkout source
uses: actions/checkout@master
path: ${{ go.module-path }} # Line 22
- name: Install server dependencies
working-directory: ${{ go.module-path }}
run: go get -v -t -d -u ./server
- name: Build server
working-directory: ${{ go.module-path }}
run: go build ./server
Minimal reproduce case would be the golang starter workflow: https://github.com/actions/starter-workflows/blob/329e9a8e162a10b5e131d13efb78e57a5b86fdd6/ci/go.yml
Good afternoon, I am using the checkout with sumbodule cloning like this:
- uses: actions/checkout@v1
with:
submodules: true
It does not seem to be recrusive, I have submodule that has submodules of its own.
If I run git submodule update --init --recursive then I get everything I need, with just the submodule:true flag that does not seem to be the case.
Am I doing something wrong?
My submodule is this one:
https://github.com/GPUOpen-Tools/Compressonator
- name: checkout
uses: actions/checkout@master
with:
submodules: recursive
fetch-depth: 1
token: ${{ secrets.OWNER_PAT }}
[submodule "themes"]
path = themes
url = https://[email protected]/owner/repo.git
The point is the user has to be added in https url, because of the error:
##[error]fatal: could not read Username for 'https://github.com': terminal prompts disabled
##[error]fatal: clone of 'https://github.com/owner/repo.git' into submodule path '/foo/themes' failed
But when add URL with a owner@
and other user (not an owner) will want to do git submodule update
, then he will be prompted about owner
password.
So using current method of authorisation with token
for user which is set in submodule HTTPS URL is not functional.
How to solve it? Deploy key? Let set also user
as parameter in action?
Just discovered it works on actions/checkout@v1
. But issue still valid for @master
and generally worth to implement deploy keys.
$GITHUB_WORKSPACE moves when using with.path on repo where action is executed (or when first fired?)
Repository is current at '/home/runner/work/repo/repo', move to '/home/runner/work/repo/site'.
This looks like it was intended by the author, but there's no (documented) way to avoid this.
In my use-case, I have 2 repo's: One with my site's files and one with ansible-playbooks for deployment:
- uses: actions/checkout@v1
with:
repository: ${{ github.repo }}
ref: ${{ github.sha }}
path: $GITHUB_WORKSPACE/site
- uses: actions/checkout@v1
with:
repository: user/ansible
ref: master
token: ${{ secrets.GIT_PAT }}
path: $GITHUB_WORKSPACE/ansible
fetch-depth: 1
The goal is to have both of these available in a docker action $GITHUB_WORKSPACE, so I have access to both repo's inside a docker action. I know there are other solutions for this, but this is the most elegant way.
-edit- I experienced this gives issues with .github/* files not being on their expected places, so I understand that $GITHUB_WORKSPACE has to move with its primary repo. I'd still like to know how I then would be able to achieve something like mentioned above.
I'm sorry if this is not the right place for this issue, but it's where it looked most appropriate to me.
When re-triggering a workflow for the PR #620 in the Jaeger Operator, the checkout step fails with:
git checkout --progress --force 76143e9bd1c40fc0b71fd45a987c80b9db0a9096
##[error]fatal: reference is not a tree: 76143e9bd1c40fc0b71fd45a987c80b9db0a9096
Removed matchers: 'checkout-git'
##[remove-matcher owner=checkout-git]
##[error]Git checkout failed with exit code: 128
##[error]Exit code 1 returned from process: file name '/home/runner/runners/2.157.0/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Repository.CheckoutTask, Runner.Plugins"'.
I can confirm that the commit exists in the fork, so, I'm not sure what the action is complaining about:
$ git remote add rubenvp8510 https://github.com/rubenvp8510/jaeger-operator
$ git fetch rubenvp8510
remote: Enumerating objects: 44, done.
remote: Counting objects: 100% (44/44), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 53 (delta 41), reused 43 (delta 41), pack-reused 9
Unpacking objects: 100% (53/53), done.
From https://github.com/rubenvp8510/jaeger-operator
* [new branch] Issue-304 -> rubenvp8510/Issue-304
* [new branch] Issue-399 -> rubenvp8510/Issue-399
* [new branch] Issue-442 -> rubenvp8510/Issue-442
* [new branch] Issue-443 -> rubenvp8510/Issue-443
* [new branch] Issue-557 -> rubenvp8510/Issue-557
* [new branch] Issue-568 -> rubenvp8510/Issue-568
* [new branch] Issue-598 -> rubenvp8510/Issue-598
* [new branch] master -> rubenvp8510/master
* [new branch] revert-391-streame2e -> rubenvp8510/revert-391-streame2e
* [new branch] token-propagation -> rubenvp8510/token-propagation
$ git checkout --progress --force 76143e9bd1c40fc0b71fd45a987c80b9db0a9096
Note: checking out '76143e9bd1c40fc0b71fd45a987c80b9db0a9096'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 76143e9b add resource limits for spark dependencies cronjob
Is it possible to extend the parameters to update submodules by --recursive or make it configurable?
When using this action it leaves the repository in a "detached HEAD" state. Is there a way to checkout the branch that initiated the workflow in an attached, usable state?
The checkout for Actions v1 using the HCL workflows worked differently and didn't leave the repository in a "detached HEAD" state.
I'm just wondering how this works at all and if I can make similar code-free actions.
Apologies if this has already come up...I haven't been able to find an answer to this.
I'm attempting to setup Actions for a private GitHub repo. The repo pulls in two submodules, each of which are also private GitHub repos. My Action fails on checkout with ##[error]fatal: Could not read from remote repository.
How do I configure the checkout action with the right credentials to pull in these private submodules?
This is what I currently have for the checkout step as a starting point:
- uses: actions/checkout@v1
with:
submodules: true
I'm experimenting with Github Actions on a large code repository at $WORK
. We use a mix of Concourse ci and Jenkins and are looking towards Github Actions as a potential CI/CD tool with less hosting maintenance.
In some simple experiments we found the actions/checkout command to be slower that expected. A checkout step takes ~6m 53s
using with.fetch-depth: 1
, and that's before my job can do anything useful.
In our Jenkins set up we have a persistent clone that we do local clones from. In concourse we use the git resource. In both cases the process of fetching a given version of the code feels faster than actions/checkout and was wondering if there as any actions tuning parameters would could apply to speed up the process
I can see a glimpse into what the action is doing in the output.
git remote add origin https://github.com/{org}/{repo}
git config gc.auto 0
git config --get-all http.https://github.com/{org}/{repo}.extraheader
git config --get-all http.proxy
git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/heads/*:refs/remotes/origin/*
Is there a way we can opt out of features like fetching all of the tags (we have a lot of tags) or submodules (we don't use submodules)?
I started looking at want concourse git resource does to draw some comparisons. Looking here I can see it does something like a clone + checkout operation
git clone --single-branch $depthflag $uri $branchflag $destination $tagflag
cd $destination
git fetch origin refs/notes/*:refs/notes/* $tagflag
if [ "$depth" -gt 0 ]; then
"$bin_dir"/deepen_shallow_clone_until_ref_is_found_then_check_out "$depth" "$ref" "$tagflag"
else
git checkout -q "$ref"
fi
I'm not sure if that's any better or worse our experience is that it "feels" more performance that what we see with github actions/checkout.
The checkout action here makes reference to an internal checkout plugin. Please add a URL reference to that plugin.
If the container
runs as non-root user, the checkout might belows to a different user.
Example
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
container: votca/buildenv:latest
steps:
- uses: actions/checkout@master
with:
submodules: true
- run: id
- run: ls -l
The user is:
uid=1000(votca) gid=1000(votca) groups=1000(votca),10(wheel)
but the checkout is owned by uid 1001.
I get the error:
##[error]/github/workspace can not be a rooted path.
when using a workflow.yml that looks like this:
name: sentinel-test-gcp
on:
pull_request:
branches:
- master
paths:
- 'sentinel-policy-sets/gcp/**'
jobs:
sentinel-test-gcp:
runs-on: ubuntu-latest
steps:
# This step checks out the repository's code
- name: checkout-code
uses: actions/checkout@master
# This step runs `sentinel test` against the GCP policies
- name: sentinel-test-gcp
uses: rberlind/sentinel-policy-sets-for-tfc@master
with:
args: ./sentinel-policy-sets/gcp
env:
STL_ACTION_WORKING_DIR: './sentinel-policy-sets/gcp'
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
I get the same thing if I use uses: actions/checkout@v1
https://github.com/foolip/reffy/runs/205394056 ran with the workflow in https://github.com/foolip/reffy/blob/github-actions-checkout-bug-report/.github/workflows/push.yml, using this step:
- name: checkout reffy-reports
uses: actions/checkout@master
with:
repository: foolip/reffy-reports
token: ${{ secrets.REFFY_REPORTS_TOKEN }}
path: reffy-reports
REFFY_REPORTS_TOKEN was 7fdfbdbaed8a5bb8f6198d988de3348097a41a37 (since regenerated) and the following appears in the logs:
git remote add origin https://github.com/foolip/reffy-reports
git config gc.auto 0
git config --get-all http.https://github.com/foolip/reffy-reports.extraheader
git config --get-all http.proxy
git -c http.extraheader="AUTHORIZATION: basic eC1hY2Nlc3MtdG9rZW46N2ZkZmJkYmFlZDhhNWJiOGY2MTk4ZDk4OGRlMzM0ODA5N2E0MWEzNw==" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/:refs/remotes/origin/
The eC1hY2Nlc3MtdG9rZW46N2ZkZmJkYmFlZDhhNWJiOGY2MTk4ZDk4OGRlMzM0ODA5N2E0MWEzNw==
bit is x-access-token:7fdfbdbaed8a5bb8f6198d988de3348097a41a37
base64-encoded.
In other words, the secret is revealed in the logs.
jobs:
handle_labels:
if: contains(github.event.label.name, 'build-for-integration')
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@master
with:
repository: ${{ 'private-org/github-actions' }}
token: ${{ secrets.GH_TOKEN }}
fetch-depth: 1
ref: 'v1'
path: ./github-actions
- name: Check local directory structure
run: |
cd github-actions
Results in:
/home/runner/work/_temp/{hash}.sh: line 1: cd: github-actions: No such file or directory
##[error]Process completed with exit code 1.
removing / adding ./
in various combination has no effect; in addition, providing the full workspace path / variable gives the dreaded "rooted path" error.
We're observing actions/checkout
creating merge commits based on the repo's latest master SHA, rather than github.event.pull_request.base.sha
from the event that initiated the action.
This causes different merge commits across jobs within a single workflow. This is despite GITHUB_SHA
, github.sha
, github.event.pull_request.head.sha
, and github.event.pull_request.base.sha
being identical for both jobs.
This happens because a new commit was added to master between the two job runs, but the observed behavior is still surprising given that both jobs are given identical environment variables and Github event data.
GITHUB_REF=refs/pull/14/merge
GITHUB_SHA=aa0ad9298d3b4e43eb7f56bdb33af0609193dba7
Abridged ${{ github }}
context:
GITHUB_CONTEXT: {
"ref": "refs/pull/14/merge",
"sha": "aa0ad9298d3b4e43eb7f56bdb33af0609193dba7",
"head_ref": "siggy/workflow-testing",
"base_ref": "master",
"event": {
"pull_request": {
"base": {
"ref": "master",
"sha": "891c8c550cf9f3890c612e4ef5ba77fbc93ec642",
},
"head": {
"ref": "siggy/workflow-testing",
"sha": "74460e62efc34fe80862f684dad06f41f55dacc1",
},
}
},
}
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at aa0ad929 Merge 74460e62efc34fe80862f684dad06f41f55dacc1 into 891c8c550cf9f3890c612e4ef5ba77fbc93ec642
Full output:
https://github.com/siggy/linkerd2/runs/207435287#step:2:1007
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at 7efd2d0b Merge 74460e62efc34fe80862f684dad06f41f55dacc1 into 324483a653c7c09a350bc2a782080d6ea0ae533d
Note that Job 2 has created merge commit 7efd2d0b
based off of the most recent master commit 324483a653c7c09a350bc2a782080d6ea0ae533d
, despite these SHAs not appearing anywhere in the environment variables or event data.
Full output:
https://github.com/siggy/linkerd2/runs/207437496#step:2:1014
Note that the above event data references the 2nd most recent commit to master, as that was the state of master when the workflow was triggered:
$ git log --pretty=oneline | head -n2
324483a653c7c09a350bc2a782080d6ea0ae533d master branch testing
891c8c550cf9f3890c612e4ef5ba77fbc93ec642 Merge remote-tracking branch 'upstream/master'
with
/ref
configNote that setting ref: ${{ github.sha }}
or ref: ${{ github.ref }}
had no effect:
https://github.com/siggy/linkerd2/pull/14/checks?check_run_id=207481400#step:2:3
- name: Checkout code
uses: actions/checkout@v1
with:
ref: ${{ github.sha }}
Run actions/checkout@v1
with:
ref: 17c77866218c23d4b2a47221ccd9aff78a5d7172
clean: true
...
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at d6ae7796 Merge 80e75c911dbd20e9b1226d7854818843b037dc1a into ae31e8838e171e60e1cd2fa9ad54070fcb741025
https://github.com/siggy/linkerd2/pull/14/checks?check_run_id=207488293#step:2:3
- name: Checkout code
uses: actions/checkout@v1
with:
ref: ${{ github.ref }}
Run actions/checkout@v1
with:
ref: refs/pull/14/merge
clean: true
...
git checkout --progress --force refs/remotes/pull/14/merge
...
HEAD is now at eb786159 Merge 8a33bbfb6ad62902926b1449c2b9703433da6450 into ae31e8838e171e60e1cd2fa9ad54070fcb741025
...but upon further inspection of workflow environment variables opted to create an issue in this repo.
What do I wanto to achieve?
I want to deploy the master
-branch and the beta
-branch to gh-pages
at the same time. master
should go to gh-pages/
(root folder) and beta
-branch to gh-pages/beta
-folder.
My idea
Currently I'm using actions/checkout twice (in a single job) with those two different branches. First I do checkout, then npm install && npm run build
. Works quite well, until the second actions/checkout is executed. This action seems to remove the previous folder including all build results, so I'm unable to move both builds to a deploy
-folder to finally publish it to gh-pages
. See parts of my script for details:
steps:
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
- name: Checking out master
uses: actions/checkout@v1
with:
ref: master
path: master
- name: Build master
run: |
npm install
npm run build --if-present
env:
CI: true
# at this point, everything from master has been built and is on the filesystem of the runner
- name: Checking out beta
uses: actions/checkout@v1
with:
ref: beta
path: beta
# at this point, everything from master seems to be lost in the filesystem
- name: Build beta
run: |
npm install
npm run build --if-present
env:
CI: true
- name: GitHub Pages Deploy
uses: maxheld83/[email protected]
env:
BUILD_DIR: deploy/
GH_PAT: ${{ secrets.GH_PAT }}
Questions
gh-pages
?Notes
This idea works when not using actions/checkout but raw git clone
. I guess that actions/checkout runs in some sort of docker container, which will be burned after operation.
I'm trying to set up GitHub Actions for CI on Git LFS. We want to clone Git itself so that we can test against older versions, but it appears that I'm invoking things incorrectly.
I expected that the repository
argument could be an arbitrary Git remote, and I've tried https://github.com/git/git
and https://github.com/git/git.git
, both of which are public, but neither appears to work. The message I get is as follows:
with:
repository: https://github.com/git/git
path: git
ref: master
clean: true
##[error]Specified argument was out of the range of valid values.
Parameter name: https://github.com/git/git
##[error]Exit code 1 returned from process: file name '/home/runner/runners/2.157.0/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Repository.CheckoutTask, Runner.Plugins"'.
If you're interested in an example run, the "Build with latest Git" target on https://github.com/git-lfs/git-lfs/runs/198689891 should be illustrative.
Could you document the valid forms of the repository argument so that folks can figure out how to use this functionality?
I am trying to use this Action from a Workflow which responds to the pull_request
event. Specifically, I'd like it to check out the branch named master
:
on: pull_request
name: Synchronize the Pull Request Preview
jobs:
update-pr-preview:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
However, the logs show that the Action is not checking out the master
branch. Instead, it appears to be fetching the GitHub-specific "merge" reference for the pull request that triggered the Workflow. The following command is listed in the logs:
git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/11/merge:refs/remotes/pull/11/merge
This is a problem for a couple reasons.
First, subsequent steps in the Workflow use secret values. I do not want to execute the untrusted code of a pull request in the presence of those values.
Second, many people (and the automated scripts in my project) delete the pull request branch immediately after closing the pull request, causing GitHub to delete the corresponding refs/pull/XX/merge
git ref. That prevents the action from running under these conditions, even though I don't actually need the deleted ref.
After some experiments, it seems that path
argument has restrictions on what values can be used. That is, I have tried making checkout to clone the repo into GOPATH
workspace, e.g. I required the clone path to be exactly $GOPATH/src/github.com/<owner>/<repo>
, but none of the following worked as expected:
Both following variants fired an error that looked like the value of the path
couldn't be absolute:
- uses: actions/checkout@v1
with:
path: /home/runner/go/src/github.com/${{ github.repository }}
- uses: actions/checkout@v1
with:
path: ${{ runner.workspace }}/src/github.com/${{ github.repository }}
The following produced the same error, even though the path wasn't an absolute:
- uses: actions/checkout@v1
with:
path: src/github.com/${{ github.repository }}
The following worked, but checkout didn't expand the value of $GOPATH
:
- uses: actions/checkout@v1
with:
path: $GOPATH/src/github.com/${{ github.repository }}
env:
GOPATH: ${{ runner.workspace }}
The only way to made it work as I needed was the following
- uses: actions/checkout@v1
with:
path: ./src/github.com/${{ github.repository }}
With the above configuration, I could use env: GOPATH: ${{ runner.workspace }}
in the subsequent run
steps. See the full example in the PR profefe/profefe#34
That's being said, the restrictions for path
requires some clarification.
I'm trying to create an action that is triggered on a PR and tags a specified reviewer. For that I'm creating an action which uses the GitHub API to create a review request. To create this request I need the pull request number. The action is triggered by a PR, but I can't find the pull request number in the action logs.
It would be great if this action would also set the email
and name
. In order to do other git operations it is required. I am adding this to my actions to get around it:
steps:
- uses: actions/checkout@v1
- name: Setup git user
run: |
git config --global user.name "$(git --no-pager log --format=format:'%an' -n 1)"
git config --global user.email "$(git --no-pager log --format=format:'%ae' -n 1)"
Unfortunately I don't have access to the user email. It seems like these can come from the account in a more clean way here, but I guess I could also create my own action. Since this is so new I am not sure what the best way forward is so thought I would post here.
I want to set up a job that checks out the branch that was pushed. Is it possible to do something like this?
- uses: actions/checkout@${GITHUB_REF}
Reference: https://help.github.com/en/articles/virtual-environments-for-github-actions#environment-variables
I'm trying to introduce GitHub actions to a repository that uses git describe --tags
as a step. For some reason, the fetches on a private repository of my organization does a fetch with --no-tags
.
My experiments in an experimental repo with the tagging feature inside GitHub show it fetching with --tags
. The logic of this action isn't contained in the source code of this repo so I'm not sure why it's doing this kind of fetch. If this is a difference in behavior between lightweight tags and annotated tags, this behavior should be documented.
Hello everyone,
I've tried to implement a basic dotnet build action on a github repository that contains one submodule which its a private repository itself.
git submodule sync
git -c http.https://github.com.extraheader="AUTHORIZATION: basic ***" submodule update --init --force
Submodule 'libs/PrivateRepo' ([email protected]:BSanchidrian/PrivateRepo.git) registered for path 'libs/PrivateRepo'
Cloning into '/home/runner/work/TestProject/libs/PrivateRepo'...
Host key verification failed.
##[error]fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
##[error]fatal: clone of '[email protected]:BSanchidrian/PrivateRepo.git' into submodule path '/home/runner/work/TestProject/libs/PrivateRepo' failed
Failed to clone 'libs/PrivateRepo'. Retry scheduled
Cloning into '/home/runner/work/TestProject/libs/PrivateRepo'...
Host key verification failed.
##[error]fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
##[error]fatal: clone of '[email protected]:BSanchidrian/PrivateRepo.git' into submodule path '/home/runner/work/TestProject/libs/PrivateRepo' failed
Failed to clone 'libs/PrivateRepo' a second time, aborting
Removed matchers: 'checkout-git'
##[remove-matcher owner=checkout-git]
##[error]Git submodule update failed with exit code: 1
##[error]Exit code 1 returned from process: file name '/home/runner/runners/2.157.3/bin/Runner.PluginHost', arguments 'action "GitHub.Runner.Plugins.Repository.CheckoutTask, Runner.Plugins"'.
When I create a PR, actions/checkout
checks out the head of the PR branch. For example, if the head of the PR branch has the SHA cc87b2733dfbe579a4451b2359191a6c512207c3
, I see this in the GitHub CI log:
git checkout --progress --force cc87b2733dfbe579a4451b2359191a6c512207c3
Whereas most CI systems check out the test merge of the PR. For example, if the PR number is 123, in the Travis CI log I see:
git fetch origin +refs/pull/123/merge
git checkout -qf FETCH_HEAD
And in the Appveyor log I see:
git fetch -q origin +refs/pull/123/merge
git checkout -qf FETCH_HEAD
actions/checkout
should check out the test merge of a PR, rather than the head of the PR branch. Or it should at least have an option to do that.
We are creating an action called deploy
and current branch is newsite
so as per this documentation we want to use newsite
branch but if I don't specify the branch then also it works.
Refer: numpy/numpy.org#46 (comment)
Note the SHA at the top of my build:
But this is the output from the end of actions/checkout
:
HEAD is now at c28ff3a5b fix: Use React 16.9.0.
Removed matchers: 'checkout-git'
##[remove-matcher owner=checkout-git]
It seems to be checking out the latest master, instead of the branch I'm actually on. This was working on Saturday.
Please print out the commit hash for the commit which is successfully checked out by this action.
I'd like to confirm what happens when I just use the checkout action with all defaults, such as in the below:
name: Document Conversion
on: push
jobs:
convert_via_pandoc:
name: Convert via Pandoc
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- uses: maxheld83/pandoc@master
with:
args: "--standalone --output=index.html README.md"
My assumption would be that behind the scenes something like git clone
and git checkout $GITHUB_SHA
happens, so that this always puts whatever git ref the push
event brought along into GITHUB_WORKSPACE
.
The docs are a little hazy on this:
To create a specific copy of your repository, you can checkout a specific branch, SHA, or tag from your repository, with the with syntax:
- uses: actions/checkout@master with: ref: refs/heads/master
They don't however state explicitly what the default behavior is.
I've tested this empirically and I seem to be correct, but I'd like to be certain.
Would be nice to
Right now git fetch
is executed with --no-tags
by default and there is no option available to change this. It would be particularly useful (especially for tag based versioning) to support a tags: true
property on this action which removes the --no-tags
flag from the fetch operation.
I noticed the documentation for actions
says I can't call an action in another private repo that I own. I have a different question. Is it possible to use the checkout action (of my repo) to checkout a public repo, or a private repo owned by me? This would be useful for pulling the latest version of C++ boost header libraries, or another library I wrote that's needed for the build.
failed on platform: windows-latest
2019-09-27T05:29:49.9466950Z Current runner version: '2.158.0'
2019-09-27T05:29:49.9503146Z Prepare workflow directory
2019-09-27T05:29:50.0930139Z Prepare all required actions
2019-09-27T05:29:50.1383217Z Download action repository 'actions/checkout@v1'
2019-09-27T05:29:52.0187864Z ##[group]Run actions/checkout@v1
2019-09-27T05:29:52.0259666Z with:
2019-09-27T05:29:52.0259839Z clean: true
2019-09-27T05:29:52.0259910Z ##[endgroup]
2019-09-27T05:29:52.6339238Z Added matchers: 'checkout-git'. Problem matchers scan action output for known warning or error strings and report these inline.
2019-09-27T05:29:52.6339441Z ##[add-matcher]D:\a_temp\git_ef87972c-8e28-4589-a22e-d744740f1a8b.json
2019-09-27T05:29:52.6352569Z Syncing repository: Kuloud/AoE
2019-09-27T05:29:52.6520897Z ##[command]git version
2019-09-27T05:29:52.7172165Z git version 2.23.0.windows.1
2019-09-27T05:29:52.7255275Z ##[command]git lfs version
2019-09-27T05:29:53.8908165Z git-lfs/2.8.0 (GitHub; windows amd64; go 1.12.2; git 30af66bb)
2019-09-27T05:29:53.9232941Z ##[command]git init "D:\a\AoE\AoE"
2019-09-27T05:29:54.0608897Z Initialized empty Git repository in D:/a/AoE/AoE/.git/
2019-09-27T05:29:54.0687373Z ##[command]git remote add origin https://github.com/Kuloud/AoE
2019-09-27T05:29:54.1471494Z ##[command]git config gc.auto 0
2019-09-27T05:29:54.2080911Z ##[command]git config --get-all http.https://github.com/Kuloud/AoE.extraheader
2019-09-27T05:29:54.2488547Z ##[command]git config --get-all http.proxy
2019-09-27T05:29:54.2962949Z ##[command]git -c http.extraheader="AUTHORIZATION: basic " fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/:refs/remotes/origin/
2019-09-27T05:29:55.8933730Z remote: Enumerating objects: 24, done.
2019-09-27T05:29:55.8934444Z remote: Counting objects: 4% (1/24)
2019-09-27T05:29:55.8934655Z remote: Counting objects: 8% (2/24)
2019-09-27T05:29:55.8934829Z remote: Counting objects: 12% (3/24)
2019-09-27T05:29:55.8935061Z remote: Counting objects: 16% (4/24)
2019-09-27T05:29:55.8935273Z remote: Counting objects: 20% (5/24)
2019-09-27T05:29:55.8935445Z remote: Counting objects: 25% (6/24)
2019-09-27T05:29:55.8935630Z remote: Counting objects: 29% (7/24)
2019-09-27T05:29:55.8935910Z remote: Counting objects: 33% (8/24)
2019-09-27T05:29:55.8936241Z remote: Counting objects: 37% (9/24)
2019-09-27T05:29:55.8936343Z remote: Counting objects: 41% (10/24)
2019-09-27T05:29:55.8936490Z remote: Counting objects: 45% (11/24)
2019-09-27T05:29:55.8936668Z remote: Counting objects: 50% (12/24)
2019-09-27T05:29:55.8937029Z remote: Counting objects: 54% (13/24)
2019-09-27T05:29:55.8937146Z remote: Counting objects: 58% (14/24)
2019-09-27T05:29:55.8937437Z remote: Counting objects: 62% (15/24)
2019-09-27T05:29:55.8982568Z remote: Counting objects: 66% (16/24)
2019-09-27T05:29:55.8983711Z remote: Counting objects: 70% (17/24)
2019-09-27T05:29:55.8984540Z remote: Counting objects: 75% (18/24)
2019-09-27T05:29:56.6410015Z remote: Counting objects: 79% (19/24)
2019-09-27T05:29:56.6412005Z remote: Counting objects: 83% (20/24)
2019-09-27T05:29:56.6412424Z remote: Counting objects: 87% (21/24)
2019-09-27T05:29:56.6412665Z remote: Counting objects: 91% (22/24)
2019-09-27T05:29:56.6412887Z remote: Counting objects: 95% (23/24)
2019-09-27T05:29:56.6413104Z remote: Counting objects: 100% (24/24)
2019-09-27T05:29:56.6413622Z remote: Counting objects: 100% (24/24), done.
2019-09-27T05:29:56.6413901Z remote: Compressing objects: 6% (1/16)
2019-09-27T05:29:56.6414163Z remote: Compressing objects: 12% (2/16)
2019-09-27T05:29:56.6414376Z remote: Compressing objects: 18% (3/16)
2019-09-27T05:29:56.6414636Z remote: Compressing objects: 25% (4/16)
2019-09-27T05:29:56.6414929Z remote: Compressing objects: 31% (5/16)
2019-09-27T05:29:56.6417866Z remote: Compressing objects: 37% (6/16)
2019-09-27T05:29:56.6418114Z remote: Compressing objects: 43% (7/16)
2019-09-27T05:29:56.6418342Z remote: Compressing objects: 50% (8/16)
2019-09-27T05:29:56.6419792Z remote: Compressing objects: 56% (9/16)
2019-09-27T05:29:56.6420250Z remote: Compressing objects: 62% (10/16)
2019-09-27T05:29:56.6420486Z remote: Compressing objects: 68% (11/16)
2019-09-27T05:29:56.6420875Z remote: Compressing objects: 75% (12/16)
2019-09-27T05:29:56.6421127Z remote: Compressing objects: 81% (13/16)
2019-09-27T05:29:56.6421345Z remote: Compressing objects: 87% (14/16)
2019-09-27T05:29:56.6421552Z remote: Compressing objects: 93% (15/16)
2019-09-27T05:29:56.6421764Z remote: Compressing objects: 100% (16/16)
2019-09-27T05:29:56.6421977Z remote: Compressing objects: 100% (16/16), done.
2019-09-27T05:29:56.6422119Z
2019-09-27T05:29:56.6422335Z �[KReceiving objects: 0% (1/755)
2019-09-27T05:29:56.6422530Z
2019-09-27T05:29:56.6422726Z �[KReceiving objects: 1% (8/755)
2019-09-27T05:29:56.6422854Z
2019-09-27T05:29:56.6423074Z �[KReceiving objects: 2% (16/755)
2019-09-27T05:29:56.6423352Z
2019-09-27T05:29:56.6423857Z �[KReceiving objects: 3% (23/755)
2019-09-27T05:29:56.6424023Z
2019-09-27T05:29:56.6424852Z �[KReceiving objects: 4% (31/755)
2019-09-27T05:29:56.6425082Z
2019-09-27T05:29:56.6425326Z �[KReceiving objects: 5% (38/755)
2019-09-27T05:29:56.6425490Z
2019-09-27T05:29:56.6425740Z �[KReceiving objects: 6% (46/755)
2019-09-27T05:29:56.6425963Z
2019-09-27T05:29:56.6426229Z �[KReceiving objects: 7% (53/755)
2019-09-27T05:29:56.6426398Z
2019-09-27T05:29:56.6426645Z �[KReceiving objects: 8% (61/755)
2019-09-27T05:29:56.6427186Z
2019-09-27T05:29:56.6427334Z �[KReceiving objects: 9% (68/755)
2019-09-27T05:29:56.6427507Z
2019-09-27T05:29:56.6427697Z �[KReceiving objects: 10% (76/755)
2019-09-27T05:29:56.6427821Z
2019-09-27T05:29:56.6428105Z �[KReceiving objects: 11% (84/755)
2019-09-27T05:29:56.6428291Z
2019-09-27T05:29:56.6428482Z �[KReceiving objects: 12% (91/755)
2019-09-27T05:29:56.6428606Z
2019-09-27T05:29:56.6428838Z �[KReceiving objects: 13% (99/755)
2019-09-27T05:29:56.6429015Z
2019-09-27T05:29:56.6429257Z �[KReceiving objects: 14% (106/755)
2019-09-27T05:29:56.6429386Z
2019-09-27T05:29:56.6429585Z �[KReceiving objects: 15% (114/755)
2019-09-27T05:29:56.6429758Z
2019-09-27T05:29:56.6429950Z �[KReceiving objects: 16% (121/755)
2019-09-27T05:29:56.6430076Z
2019-09-27T05:29:56.6430270Z �[KReceiving objects: 17% (129/755)
2019-09-27T05:29:56.6430464Z
2019-09-27T05:29:56.6430660Z �[KReceiving objects: 18% (136/755)
2019-09-27T05:29:56.6430787Z
2019-09-27T05:29:56.6431007Z �[KReceiving objects: 19% (144/755)
2019-09-27T05:29:56.6431183Z
2019-09-27T05:29:56.6431334Z �[KReceiving objects: 20% (151/755)
2019-09-27T05:29:56.6431508Z
2019-09-27T05:29:56.6431697Z �[KReceiving objects: 21% (159/755)
2019-09-27T05:29:56.6431832Z
2019-09-27T05:29:56.6432028Z �[KReceiving objects: 22% (167/755)
2019-09-27T05:29:56.6432201Z
2019-09-27T05:29:56.6432409Z �[KReceiving objects: 23% (174/755)
2019-09-27T05:29:56.6432550Z
2019-09-27T05:29:56.6432750Z �[KReceiving objects: 24% (182/755)
2019-09-27T05:29:56.6432922Z
2019-09-27T05:29:56.6433114Z �[KReceiving objects: 25% (189/755)
2019-09-27T05:29:56.6433237Z
2019-09-27T05:29:56.6433708Z �[KReceiving objects: 26% (197/755)
2019-09-27T05:29:56.6433930Z
2019-09-27T05:29:56.6434168Z �[KReceiving objects: 27% (204/755)
2019-09-27T05:29:56.6434330Z
2019-09-27T05:29:56.6434576Z �[KReceiving objects: 28% (212/755)
2019-09-27T05:29:56.6434815Z
2019-09-27T05:29:56.6435004Z �[KReceiving objects: 29% (219/755)
2019-09-27T05:29:56.6435219Z
2019-09-27T05:29:56.6435456Z �[KReceiving objects: 30% (227/755)
2019-09-27T05:29:56.6435617Z
2019-09-27T05:29:56.6435861Z �[KReceiving objects: 31% (235/755)
2019-09-27T05:29:56.6436078Z
2019-09-27T05:29:56.6437270Z �[KReceiving objects: 32% (242/755)
2019-09-27T05:29:56.6437407Z
2019-09-27T05:29:56.6437607Z �[KReceiving objects: 33% (250/755)
2019-09-27T05:29:56.6437781Z
2019-09-27T05:29:56.6438314Z �[KReceiving objects: 34% (257/755)
2019-09-27T05:29:56.6438525Z
2019-09-27T05:29:56.6438749Z �[KReceiving objects: 35% (265/755)
2019-09-27T05:29:56.6438929Z
2019-09-27T05:29:56.6439246Z �[KReceiving objects: 36% (272/755)
2019-09-27T05:29:56.6439376Z
2019-09-27T05:29:56.6439575Z �[KReceiving objects: 37% (280/755)
2019-09-27T05:29:56.6439745Z
2019-09-27T05:29:56.6439935Z �[KReceiving objects: 38% (287/755)
2019-09-27T05:29:56.6440058Z
2019-09-27T05:29:56.6440253Z �[KReceiving objects: 39% (295/755)
2019-09-27T05:29:56.6440497Z
2019-09-27T05:29:56.6440696Z �[KReceiving objects: 40% (302/755)
2019-09-27T05:29:56.6440823Z
2019-09-27T05:29:56.6441022Z �[KReceiving objects: 41% (310/755)
2019-09-27T05:29:56.6441198Z
2019-09-27T05:29:56.6441390Z �[KReceiving objects: 42% (318/755)
2019-09-27T05:29:56.6441528Z
2019-09-27T05:29:56.6441730Z �[KReceiving objects: 43% (325/755)
2019-09-27T05:29:56.6441901Z
2019-09-27T05:29:56.6442101Z �[KReceiving objects: 44% (333/755)
2019-09-27T05:29:56.6442238Z
2019-09-27T05:29:56.6442457Z �[KReceiving objects: 45% (340/755)
2019-09-27T05:29:56.6442624Z
2019-09-27T05:29:56.6442948Z �[KReceiving objects: 46% (348/755)
2019-09-27T05:29:56.6443124Z
2019-09-27T05:29:56.6443782Z �[KReceiving objects: 47% (355/755)
2019-09-27T05:29:56.6443951Z
2019-09-27T05:29:56.6444195Z �[KReceiving objects: 48% (363/755)
2019-09-27T05:29:56.6444414Z
2019-09-27T05:29:56.6444656Z �[KReceiving objects: 49% (370/755)
2019-09-27T05:29:56.6444816Z
2019-09-27T05:29:56.6445080Z �[KReceiving objects: 50% (378/755)
2019-09-27T05:29:56.6445291Z
2019-09-27T05:29:56.6445527Z �[KReceiving objects: 51% (386/755)
2019-09-27T05:29:56.6445687Z
2019-09-27T05:29:56.6445932Z �[KReceiving objects: 52% (393/755)
2019-09-27T05:29:56.6446160Z
2019-09-27T05:29:56.6446397Z �[KReceiving objects: 53% (401/755)
2019-09-27T05:29:56.6446557Z
2019-09-27T05:29:56.6446967Z �[KReceiving objects: 54% (408/755)
2019-09-27T05:29:56.6447315Z
2019-09-27T05:29:56.6447525Z �[KReceiving objects: 55% (416/755)
2019-09-27T05:29:56.6447652Z
2019-09-27T05:29:56.6447841Z �[KReceiving objects: 56% (423/755)
2019-09-27T05:29:56.6448001Z
2019-09-27T05:29:56.6448146Z �[KReceiving objects: 57% (431/755)
2019-09-27T05:29:56.6448313Z
2019-09-27T05:29:56.6448497Z �[KReceiving objects: 58% (438/755)
2019-09-27T05:29:56.6448614Z
2019-09-27T05:29:56.6448803Z �[KReceiving objects: 59% (446/755)
2019-09-27T05:29:56.6448970Z
2019-09-27T05:29:56.6449152Z �[KReceiving objects: 60% (453/755)
2019-09-27T05:29:56.6449270Z
2019-09-27T05:29:56.6449473Z �[KReceiving objects: 61% (461/755)
2019-09-27T05:29:56.6449640Z
2019-09-27T05:29:56.6449824Z �[KReceiving objects: 62% (469/755)
2019-09-27T05:29:56.6449943Z
2019-09-27T05:29:56.6450130Z �[KReceiving objects: 63% (476/755)
2019-09-27T05:29:56.6450302Z
2019-09-27T05:29:56.6450489Z �[KReceiving objects: 64% (484/755)
2019-09-27T05:29:56.6450607Z
2019-09-27T05:29:56.6450790Z �[KReceiving objects: 65% (491/755)
2019-09-27T05:29:56.6450961Z
2019-09-27T05:29:56.6451101Z �[KReceiving objects: 66% (499/755)
2019-09-27T05:29:56.6451291Z
2019-09-27T05:29:56.6451478Z �[KReceiving objects: 67% (506/755)
2019-09-27T05:29:56.6451595Z
2019-09-27T05:29:56.6451786Z �[KReceiving objects: 68% (514/755)
2019-09-27T05:29:56.6451951Z
2019-09-27T05:29:56.6452133Z �[KReceiving objects: 69% (521/755)
2019-09-27T05:29:56.6452252Z
2019-09-27T05:29:56.6452441Z �[KReceiving objects: 70% (529/755)
2019-09-27T05:29:56.6452606Z
2019-09-27T05:29:56.6452789Z �[KReceiving objects: 71% (537/755)
2019-09-27T05:29:56.6452907Z
2019-09-27T05:29:56.6453112Z �[KReceiving objects: 72% (544/755)
2019-09-27T05:29:56.6453275Z
2019-09-27T05:29:56.6453899Z �[KReceiving objects: 73% (552/755)
2019-09-27T05:29:56.6454403Z
2019-09-27T05:29:56.6454672Z �[KReceiving objects: 74% (559/755)
2019-09-27T05:29:56.6454896Z
2019-09-27T05:29:56.6455139Z �[KReceiving objects: 75% (567/755)
2019-09-27T05:29:56.6455299Z
2019-09-27T05:29:56.6455638Z �[KReceiving objects: 76% (574/755)
2019-09-27T05:29:56.6455888Z
2019-09-27T05:29:56.6456084Z �[KReceiving objects: 77% (582/755)
2019-09-27T05:29:56.6456345Z
2019-09-27T05:29:56.6456589Z �[KReceiving objects: 78% (589/755)
2019-09-27T05:29:56.6456804Z
2019-09-27T05:29:56.6457048Z �[KReceiving objects: 79% (597/755)
2019-09-27T05:29:56.6457261Z
2019-09-27T05:29:56.6457500Z �[KReceiving objects: 80% (604/755)
2019-09-27T05:29:56.6457821Z
2019-09-27T05:29:56.6458006Z �[KReceiving objects: 81% (612/755)
2019-09-27T05:29:56.6458174Z
2019-09-27T05:29:56.6458377Z �[KReceiving objects: 82% (620/755)
2019-09-27T05:29:56.6458503Z
2019-09-27T05:29:56.6458691Z �[KReceiving objects: 83% (627/755)
2019-09-27T05:29:56.6458858Z
2019-09-27T05:29:56.6459043Z �[KReceiving objects: 84% (635/755)
2019-09-27T05:29:56.6459174Z
2019-09-27T05:29:56.6459366Z �[KReceiving objects: 85% (642/755)
2019-09-27T05:29:56.6459526Z
2019-09-27T05:29:56.6459713Z �[KReceiving objects: 86% (650/755)
2019-09-27T05:29:56.6459836Z
2019-09-27T05:29:56.6460024Z �[KReceiving objects: 87% (657/755)
2019-09-27T05:29:56.6460138Z
2019-09-27T05:29:56.6460388Z �[KReceiving objects: 88% (665/755)
2019-09-27T05:29:56.6460555Z
2019-09-27T05:29:56.6460736Z �[KReceiving objects: 89% (672/755)
2019-09-27T05:29:56.6460856Z
2019-09-27T05:29:56.6461042Z �[KReceiving objects: 90% (680/755)
2019-09-27T05:29:56.6461248Z remote: Total 755 (delta 8), reused 0 (delta 0), pack-reused 731
2019-09-27T05:29:56.6461426Z
2019-09-27T05:29:56.6461607Z �[KReceiving objects: 91% (688/755)
2019-09-27T05:29:56.6461725Z
2019-09-27T05:29:56.6461911Z �[KReceiving objects: 92% (695/755)
2019-09-27T05:29:56.6462090Z
2019-09-27T05:29:56.6462272Z �[KReceiving objects: 93% (703/755)
2019-09-27T05:29:56.6462403Z
2019-09-27T05:29:56.6462590Z �[KReceiving objects: 94% (710/755)
2019-09-27T05:29:56.6462755Z
2019-09-27T05:29:56.6462944Z �[KReceiving objects: 95% (718/755)
2019-09-27T05:29:56.6463062Z
2019-09-27T05:29:56.6463283Z �[KReceiving objects: 96% (725/755)
2019-09-27T05:29:56.6463655Z
2019-09-27T05:29:56.6463851Z �[KReceiving objects: 97% (733/755)
2019-09-27T05:29:56.6464067Z
2019-09-27T05:29:56.6464331Z �[KReceiving objects: 98% (740/755)
2019-09-27T05:29:56.6464498Z
2019-09-27T05:29:56.6464741Z �[KReceiving objects: 99% (748/755)
2019-09-27T05:29:56.6464968Z
2019-09-27T05:29:56.6465216Z �[KReceiving objects: 100% (755/755)
2019-09-27T05:29:56.6465429Z
2019-09-27T05:29:56.6465685Z �[KReceiving objects: 100% (755/755), 6.20 MiB | 31.73 MiB/s, done.
2019-09-27T05:29:56.6465855Z
2019-09-27T05:29:56.6466099Z �[KResolving deltas: 0% (0/113)
2019-09-27T05:29:56.6466310Z
2019-09-27T05:29:56.6466567Z �[KResolving deltas: 1% (2/113)
2019-09-27T05:29:56.6467055Z
2019-09-27T05:29:56.6467242Z �[KResolving deltas: 10% (12/113)
2019-09-27T05:29:56.6467405Z
2019-09-27T05:29:56.6467857Z �[KResolving deltas: 18% (21/113)
2019-09-27T05:29:56.6468154Z
2019-09-27T05:29:56.6468411Z �[KResolving deltas: 20% (23/113)
2019-09-27T05:29:56.6468581Z
2019-09-27T05:29:56.6468765Z �[KResolving deltas: 22% (25/113)
2019-09-27T05:29:56.6468885Z
2019-09-27T05:29:56.6469068Z �[KResolving deltas: 23% (26/113)
2019-09-27T05:29:56.6469184Z
2019-09-27T05:29:56.6469398Z �[KResolving deltas: 24% (28/113)
2019-09-27T05:29:56.6469563Z
2019-09-27T05:29:56.6469744Z �[KResolving deltas: 25% (29/113)
2019-09-27T05:29:56.6469907Z
2019-09-27T05:29:56.6470093Z �[KResolving deltas: 26% (30/113)
2019-09-27T05:29:56.6470415Z
2019-09-27T05:29:56.6470598Z �[KResolving deltas: 28% (32/113)
2019-09-27T05:29:56.6470715Z
2019-09-27T05:29:56.6470906Z �[KResolving deltas: 29% (33/113)
2019-09-27T05:29:56.6471085Z
2019-09-27T05:29:56.6471269Z �[KResolving deltas: 30% (34/113)
2019-09-27T05:29:56.6471533Z
2019-09-27T05:29:56.6471727Z �[KResolving deltas: 31% (36/113)
2019-09-27T05:29:56.6471893Z
2019-09-27T05:29:56.6472700Z �[KResolving deltas: 36% (41/113)
2019-09-27T05:29:56.6486094Z
2019-09-27T05:29:56.6487159Z �[KResolving deltas: 37% (42/113)
2019-09-27T05:29:56.6487502Z
2019-09-27T05:29:56.6487772Z �[KResolving deltas: 38% (44/113)
2019-09-27T05:29:56.6488039Z
2019-09-27T05:29:56.6488386Z �[KResolving deltas: 39% (45/113)
2019-09-27T05:29:56.6488615Z
2019-09-27T05:29:56.6489111Z �[KResolving deltas: 40% (46/113)
2019-09-27T05:29:56.6489384Z
2019-09-27T05:29:56.6489697Z �[KResolving deltas: 43% (49/113)
2019-09-27T05:29:56.6489914Z
2019-09-27T05:29:56.6490233Z �[KResolving deltas: 44% (50/113)
2019-09-27T05:29:56.6491222Z
2019-09-27T05:29:56.6491729Z �[KResolving deltas: 45% (51/113)
2019-09-27T05:29:56.6492845Z
2019-09-27T05:29:56.6493862Z �[KResolving deltas: 46% (52/113)
2019-09-27T05:29:56.6494405Z
2019-09-27T05:29:56.6494929Z �[KResolving deltas: 47% (54/113)
2019-09-27T05:29:56.6495269Z
2019-09-27T05:29:56.6495743Z �[KResolving deltas: 48% (55/113)
2019-09-27T05:29:56.6496158Z
2019-09-27T05:29:56.6496563Z �[KResolving deltas: 50% (57/113)
2019-09-27T05:29:56.6497296Z
2019-09-27T05:29:56.6498220Z �[KResolving deltas: 51% (58/113)
2019-09-27T05:29:56.6498503Z
2019-09-27T05:29:56.6498903Z �[KResolving deltas: 52% (59/113)
2019-09-27T05:29:56.6499253Z
2019-09-27T05:29:56.6499900Z �[KResolving deltas: 53% (60/113)
2019-09-27T05:29:56.6500209Z
2019-09-27T05:29:56.6500629Z �[KResolving deltas: 55% (63/113)
2019-09-27T05:29:56.6500983Z
2019-09-27T05:29:56.6501574Z �[KResolving deltas: 56% (64/113)
2019-09-27T05:29:56.6501774Z
2019-09-27T05:29:56.6502026Z �[KResolving deltas: 57% (65/113)
2019-09-27T05:29:56.6502402Z
2019-09-27T05:29:56.6502793Z �[KResolving deltas: 58% (66/113)
2019-09-27T05:29:56.6502952Z
2019-09-27T05:29:56.6503180Z �[KResolving deltas: 59% (67/113)
2019-09-27T05:29:56.6503979Z
2019-09-27T05:29:56.6504290Z �[KResolving deltas: 60% (68/113)
2019-09-27T05:29:56.6504488Z
2019-09-27T05:29:56.6504779Z �[KResolving deltas: 61% (69/113)
2019-09-27T05:29:56.6505022Z
2019-09-27T05:29:56.6505270Z �[KResolving deltas: 62% (71/113)
2019-09-27T05:29:56.6505528Z
2019-09-27T05:29:56.6505807Z �[KResolving deltas: 63% (72/113)
2019-09-27T05:29:56.6506220Z
2019-09-27T05:29:56.6506659Z �[KResolving deltas: 64% (73/113)
2019-09-27T05:29:56.6507223Z
2019-09-27T05:29:56.6507444Z �[KResolving deltas: 65% (74/113)
2019-09-27T05:29:56.6507576Z
2019-09-27T05:29:56.6507765Z �[KResolving deltas: 66% (75/113)
2019-09-27T05:29:56.6507928Z
2019-09-27T05:29:56.6508113Z �[KResolving deltas: 69% (79/113)
2019-09-27T05:29:56.6508232Z
2019-09-27T05:29:56.6508417Z �[KResolving deltas: 72% (82/113)
2019-09-27T05:29:56.6508629Z
2019-09-27T05:29:56.6508812Z �[KResolving deltas: 76% (86/113)
2019-09-27T05:29:56.6508930Z
2019-09-27T05:29:56.6509140Z �[KResolving deltas: 82% (93/113)
2019-09-27T05:29:56.6509325Z
2019-09-27T05:29:56.6509474Z �[KResolving deltas: 92% (104/113)
2019-09-27T05:29:56.6509642Z
2019-09-27T05:29:56.6509823Z �[KResolving deltas: 93% (106/113)
2019-09-27T05:29:56.6509950Z
2019-09-27T05:29:56.6510143Z �[KResolving deltas: 99% (112/113)
2019-09-27T05:29:56.6510305Z
2019-09-27T05:29:56.6510486Z �[KResolving deltas: 100% (113/113)
2019-09-27T05:29:56.6510606Z
2019-09-27T05:29:56.6510790Z �[KResolving deltas: 100% (113/113), done.
2019-09-27T05:29:56.6511007Z From https://github.com/Kuloud/AoE
2019-09-27T05:29:56.6511245Z * [new branch] master -> origin/master
2019-09-27T05:29:56.6511457Z * [new tag] 1.0.0 -> 1.0.0
2019-09-27T05:29:56.6511776Z ##[command]git checkout --progress --force 540d27e37d5b003ececf3d1222250087f17db838
2019-09-27T05:29:57.0280845Z error: unable to create file iOS/Demo/AoE-iOSSDKDemo/Assets.xcassets/LaunchImage.launchimage/12422208.png: Invalid argument
2019-09-27T05:29:57.0282165Z error: unable to create file iOS/Demo/AoE-iOSSDKDemo/Assets.xcassets/LaunchImage.launchimage/750*1336.png: Invalid argument
2019-09-27T05:29:57.0285690Z Note: switching to '540d27e37d5b003ececf3d1222250087f17db838'.
2019-09-27T05:29:57.0287030Z
2019-09-27T05:29:57.0287962Z You are in 'detached HEAD' state. You can look around, make experimental
2019-09-27T05:29:57.0288559Z changes and commit them, and you can discard any commits you make in this
2019-09-27T05:29:57.0289136Z state without impacting any branches by switching back to a branch.
2019-09-27T05:29:57.0289641Z
2019-09-27T05:29:57.0290194Z If you want to create a new branch to retain commits you create, you may
2019-09-27T05:29:57.0290799Z do so (now or later) by using -c with the switch command. Example:
2019-09-27T05:29:57.0291250Z
2019-09-27T05:29:57.0291867Z git switch -c
2019-09-27T05:29:57.0292542Z
2019-09-27T05:29:57.0293157Z Or undo this operation with:
2019-09-27T05:29:57.0294118Z
2019-09-27T05:29:57.0294886Z git switch -
2019-09-27T05:29:57.0295642Z
2019-09-27T05:29:57.0296361Z Turn off this advice by setting config variable advice.detachedHead to false
2019-09-27T05:29:57.0297072Z
2019-09-27T05:29:57.0297507Z HEAD is now at 540d27e Update android_ci.yml
2019-09-27T05:29:57.0408597Z Removed matchers: 'checkout-git'
2019-09-27T05:29:57.0408816Z ##[remove-matcher owner=checkout-git]
2019-09-27T05:29:57.0451030Z ##[error]Git checkout failed with exit code: 1
2019-09-27T05:29:57.0926663Z ##[error]Exit code 1 returned from process: file name 'c:\runners\2.158.0\bin\Runner.PluginHost.exe', arguments 'action "GitHub.Runner.Plugins.Repository.CheckoutTask, Runner.Plugins"'.
2019-09-27T05:29:57.1053961Z Cleaning up orphan processes
I'm having issues when using actions/checkout. When it runs, I get
##[error]fatal: couldn't find remote ref refs/pull/217/merge
The line can (and full log) can be found here.
The action itself is called node-swn-build.
Do I miss some config?
Thanks in advance!
Hello,
How can I access the files between different jobs?
I have two jobs: Build and Deploy.
The Build job has the following steps:
- uses: actions/checkout@master
- name: Install Packages
run: npm install
- name: Build dist
run: npm run build
That will generate a new folder called "dist". How can I access "dist" folder contents in the Deploy job?
This is the output of running ls command in the Build job:
But the Deploy job has only the files in master branch. And doesn't contains the new "dist" folder.
I am new to github actions and not sure if this is supported currently
we would like to setup multiple conditional jobs on a single repo
is it possible to persist the checked out files accross multiple jobs
ie
task checkout code
task if has js changes
run npm install
run eslint
build & test on js
task if has .net changes
nuget restore
build & test
on .net if has changes
Since the GitHub Actions documentation isn't in an open-sourced repo so I can't file doc bugs there, as suggested at actions/setup-node#28 (comment) I'm filing a documentation bug here.
In the documentation example just above https://help.github.com/en/articles/virtual-environments-for-github-actions#exit-codes-and-statuses (step 7, a workflow file named "Workflows with large secrets"), there's a lone $
that should have been something like ${{ secrets.LARGE_SECRET_PASSPHRASE }}
, but something in the docs build process stripped the double braces.
Is there a way to specify depth
for the submodule?
Thanks!
I'd like to run an action on a pull_request and check out the actual content of the PR, not a merge with master
(because I want it to run even if there is a merge conflict among other reasons). Support for specifying this has been requested on the community forum.
I've tried the following:
with:
ref: ${{ github.ref }}^2
Which causes a failure because it tries to do:
git fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/3/merge^2:refs/remotes/pull/3/merge^2
which is an invalid refspec.
Doing this seems to just get completely ignored:
with:
ref: ${{ github.sha }}^2
I haven't found a way to use $GITHUB_SHA
yet either (it seems to be used literally when in a with
block).
Maybe related to #49.
The originating branch is saga
, however actions/checkout@v1
tries to check out master
and fails here because this repo has no master
branch:
error: pathspec 'refs/remotes/origin/master' did not match any file(s) known to git
currently the checkout performs:
git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/*
would be great to use quiet instead
git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --quiet --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/*
so the job log is cleaner to read
Can you please add an autocrlf
input that runs git config --global core.autocrlf <value>
before checkout?
My Windows builds are failing because of this. Being able to specify autocrlf: false
would fix it!
Hi there,
Without changing anything, my github actions stopped working last night and I got an error of
##[error]fatal: could not read Username for 'https://github.com': terminal prompts disabled
Does anyone know what is wrong here?
Thank you
Shi
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.