actions / checkout Goto Github PK

$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.

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

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.

Upon attempting to set the checkout path

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

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

https://github.com/NordicSemiconductor/modemtalk/commit/e9006f32481bd2bc97a35403fcb6342b8f964874/checks#step:2:586

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

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)

Is there a way to specify depth for the submodule?

Thanks!

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

Is it possible to extend the parameters to update submodules by --recursive or make it configurable?

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

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.

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.

• yml setting.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
      with:
        ref: develop
        submodules: true

• actions log
  

Please fix it. 🙏

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

1. Why is this behaviour? Am I understanding actions/checkout wrong?
2. Is there a better strategy to use to publish multiple things to 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.

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.

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.

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

• confirm that I got this right
• change the docs accordingly

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.

Identical environment between jobs

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",
      },
    }
  },
}

Job 1

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

Job 2

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

State of master

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 config

Note that setting ref: ${{ github.sha }} or ref: ${{ github.ref }} had no effect:

sha

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

ref

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

Previously reported in the Community Forum

https://github.community/t5/GitHub-API-Development-and/Github-Actions-Inconsistent-repo-checkouts-across-jobs/td-p/30258

...but upon further inspection of workflow environment variables opted to create an issue in this repo.

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.

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

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.

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 

• [new branch] master -> origin/master
  git checkout --progress --force feature/github-actions
  error: pathspec 'feature/github-actions' did not match any file(s) known to git
  Removed matchers: 'checkout-git'
  ##[remove-matcher owner=checkout-git]
  ##[error]Git checkout failed with exit code: 1
  ##[error]Exit code 1 returned from process: file name 'c:\runners\2.159.0\bin\Runner.PluginHost.exe', arguments 'action "GitHub.Runner.Plugins.Repository.v1_0.CheckoutTask, Runner.Plugins"'.

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.

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.

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.

The checkout action here makes reference to an internal checkout plugin. Please add a URL reference to that plugin.

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

I'm just wondering how this works at all and if I can make similar code-free actions.

Is there a way to checkout the code of a PR when closing the PR?

We are spinning up an environment per PR and need some config from the repo to help tear it down when closing the PR.

Currently it tries to checkout the branch based off the special github pr branch

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.

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.

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).

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!

👋 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! 🙇

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'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

Please print out the commit hash for the commit which is successfully checked out by this action.

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]:S7KYuuki/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]:S7KYuuki/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]:S7KYuuki/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"'.

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!

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.

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.

    - 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.

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 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.

For the code here:

What does plugin mean?

I cannot find any reference on the help page.

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?

• uses: actions/checkout@v1

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