actions / toolkit Goto Github PK

How can I enable the action only to run when an issue is created without setting checks... If my base branch is develop, and I have PR opened to master, every time an issue is created it's gonna assign checks to my PR. something that I don't want because the action is only used to assign users to it, no to prevent merging a PR.

how can I prevent this behavior?

Hello,
One of the steps in the Job didn't pass and so the github action check has failed.

Then I triggered the Re-run checks without changing anything. The build has skipped the step which was failed and the check has passed. Ideally It should fail again. This is not the first time, I have checked multiple times with different workflows.

After Triggering Re_run checks

Please ask me if something is not clear.

Info:

Currently @actions/core provides debug(), error() and warning(). These do not cover the use case of logging information that you would like to always show in the logs but are not necessarily an error or warning of an issue.

Feature Request:

Add an info variant to the logging provided by @actions/core

It would useful for actions to have a reliable way to get a path to the temp directory.

In tool-cache a tempDirectory path is computed from various parameters but this is not available in the exported API.

How can I understand that error occured?

I'm testing out the exec package and what I'm noticing is all of the commands that I execute are logged but the first 2 characters of the command are being cut off.

• Runner version: 2.157.5
• @actions/exec version: 1.0.1

This is the code I'm executing:

await exec.exec("dotnet-format", ["--check", "--dry-run"], options);

In the raw log I'm seeing:

[command]dotnet tool install -g dotnet-format

But in the styled log I'm seeing:

I am trying to write an action to setup flutter toolchain, but I can't extract zip.

The repo is https://github.com/chunlea/actions-setup-flutter, and code is here: https://github.com/chunlea/actions-setup-flutter/blob/master/src/installer.ts#L144

and I got this error:

2019-08-25T03:38:14.4067220Z ##[group]Run chunlea/actions-setup-flutter@releases/vtest
2019-08-25T03:38:14.4067400Z with:
2019-08-25T03:38:14.4067450Z   flutter-version: stable
2019-08-25T03:38:14.4067540Z ##[endgroup]
2019-08-25T03:38:15.1769030Z the file name is flutter_macos_v1.7.8+hotfix.4-stable.zip and .zip
2019-08-25T03:38:35.8228380Z [command]/Users/runner/runners/2.157.0/work/_actions/chunlea/actions-setup-flutter/releases/vtest/node_modules/@actions/tool-cache/scripts/externals/unzip-darwin /Users/runner/runners/2.157.0/work/_temp/a64b2350-0bc0-439f-99e4-e9eb03603b23
2019-08-25T03:38:35.8348120Z ##[error]There was an error when attempting to execute the process '/Users/runner/runners/2.157.0/work/_actions/chunlea/actions-setup-flutter/releases/vtest/node_modules/@actions/tool-cache/scripts/externals/unzip-darwin'. This may indicate the process failed to start. Error: spawn /Users/runner/runners/2.157.0/work/_actions/chunlea/actions-setup-flutter/releases/vtest/node_modules/@actions/tool-cache/scripts/externals/unzip-darwin ENOENT
2019-08-25T03:38:35.8387530Z ##[error]Node run failed with exit code 1
2019-08-25T03:38:35.8504660Z Cleaning up orphan processes

But if I change the code in @actions/tool-cache, not using the unzip in node_modules, using the unzip in system, it works.

any idea?

I am trying to get access to the user-configured job name so that my custom action can annotate it's own check run.

From documentation and sample code that I've been able to wrangle together I would expect context.action to have this value. However, it appears this is only ever the same value: [org-name]actions no matter the user-configured job

Not sure if this is the best place to ask, but is this the expected return behaviour of context.action? Is there any way to get the job name or check run ID within my action so that I can provide annotations?

I've been attempting to use the listForRef on octokit.checks but without a check_name I can't reliably assure that my annotation is happening on the correct job, especially if the user has multiple parallel ones configured:

octokit.checks.listForRef({
    check_name: action // This is always "[org-name]actions"
    owner,
    repo,
    ref: sha,
    status: 'in_progress'
})

Hello,

I'm sorry if this is not the best place to ask this, I've looked if there aren't already communities more "support-oriented", but as GitHub actions is still in beta, it seems this question hasn't been properly settled yet.

There's a core.exportVariable method which allows one to "export variables and secrets for future steps". However, I haven't found a way to do the same thing with a Docker action.
I (naïvely) tried adding something like export MY_VAR='tada' to the entrypoint.sh file from the template, but I am unable to read the variable from a subsequent step.

• Is there an equivalent of exportVariable for Docker actions? If so, I think it should be documented in the template. If not, it should also be documented 😄

Thanks for your help!

Create a getting started repo with the right patterns of gitignore, husky usage, build, test and consuming toolkit from targz + install. (that will change after public availability so we should branch it appropriately)

I am trying to write a GitHub action tool to download & setup Nuget.exe however by passing the URL

const nugetPath = await tc.downloadTool("https://dist.nuget.org/win-x86-commandline/latest/nuget.exe");

This saves the file as something like this
temp/b438b0f2-af22-456a-8a77-ddc4152465b9 minus the .exe file extension

I could workaround it by manually renaming it with using NodeJS fs APIs but this feels a bit wrong to me.

Can't run npm run format from the README - given the set of packages I couldn't make the assumption on what you were planning, so opted for a PR.

Should provide context and an authenticated github client

See #21 (specifically #21 (comment))

Cp was causing some issues, I believe specifically around how it handles symlinks.

Not sure if this is the right place to open this issue but it seems to be the only git related action that is currently available.

So the question is: can actions merge a pull request? Is there going to be a plugin for runners that allows this?

Before we start publishing, we need some build/release tooling. When it's time to release new package versions, we need to:

1. Compile TypeScript
2. Publish to NPM

Hello,

I know that the GitHub Actions will support all the events mentioned here, However, Is there any way on how we can trigger a workflow only based on sub-events like pull_request.opened pull_request.closed and not for other sub-events such as pull_request.labelled pull_request.synchronize.

Hence, If I want to trigger a workflow only based on some sub-events lets say pull_request.opened pull_request.closed but not for all the sub-events of pull_request, then what will be the best possible way to develop an Github Action for this use-case ?.

Using Actions as CI

How or where can I get a unique build number to append build Artifacts with a unique CI version

Sorry, if this is not the right place to ask for help & feedback on GitHub Actions. If so can you point me to the right place .

/cc @damccorm

From the example actions like labeler, I get the impression that the idea is to check node_modules into VCS so that the runner can resolve the dependencies of the action at runtime.

Instead of doing that, I'd much rather use a tool like webpack to bundle everything up that is necessary and only check in the generated file.
However, it seems that "@actions/github" is not compatible with that approach. My action fails at runtime because it cannot import the event.json file: https://github.com/thomaseizinger/actions-playground/runs/207679280

For now, I resorted to not use the "@actions/" dependencies and code the requests myself since they are fairly trivial.

IMO, it would be good to have examples that use webpack and a zero-dependency JavaScript file for actions.
The project I am currently working on is here: https://github.com/thomaseizinger/assign-pr-creator-action

Create a getting started repo with the right patterns

In the case of monorepos, I may wish to run a specific worklow for parts of a project, only if a specific directory containing said project changes, as to not unnecessarily pollute action output when adding features of other projects, and avoid unnecessary cpu cycle consumption of the github actions service. This of course is possible atm, with something as simple as this:

on:
  # trigger action if anything in this path changes
  push:
    paths: 
    - project3/src/*

However, I would still like to see everything tested, even if it was just other parts being changed, once it makes it into an important branch like master or develop, whilst still applying the above filter.

I would hope the following would work to achieve this, but it does not, and complains about push already having been declared:

on:
  # trigger action if anything in this path changes
  push:
    paths: 
    - project3/src/*
  # trigger always on master and develop
  push:
    branches: 
    - master
    - develop

Doing the following, simply limits the workflow to running only if the said path changes in master/develop:

on:
  # trigger action if anything in this path changes on master|develop
  push:
    paths: 
    - project3/src/*
    branches: 
    - master
    - develop

as it should in that case, but I would like to see the above work, or if it already can please enlighten me :). For now I can just trigger on all branches, as that is preferable to limited triggering even on master|develop. Preferably the above more flexible event filtering would be ideal. I understand I can use pull_requests as well (but I don't consider it sufficient), and creating a duplicate identical workflow with just a slightly different event trigger is inelegant imo.

I'm not sure where I should be posting this, or how I can report bugs, so I'm starting here. Please point me in the right direction if this isn't the forum

My goal is to eloquently handle running (or NOT running) a step based on the value of an output from a previous step. In this case i want to do custom things IF my semantic-release step actually cut a new version.

1. According to the docs it says the steps context is directly accessible via property name "steps". However when you want to use this in an jobs.<job_id>.steps.if expression, you need to access like job.steps..., i.e. if: job.steps.<step id>.status == failure

2. However the actual steps context as documented (with outputs) is NOT accessible inside an if expression

3. Everywhere else, ${{ steps..outputs }} works fine. In env it works, in run it works. Everything here works as expected:

- run: |
    printenv
    echo ${{ steps.semantic.outputs.semantic_release_version }}
    echo $VERSION
    echo "$OUTPUTS"
  env:
    VERSION: ${{ steps.semantic.outputs.semantic_release_version }}
    OUTPUTS: ${{ toJson(steps.semantic.outputs) }}

4. However, in an if expression if: steps.<step id>.outputs.someOutput == 'foo', it throws an error:

- Your workflow file was invalid: .github/workflows/test.yml (Line: 42, Col: 13): Unrecognized named-value: 'steps'. Located at position 1 within expression: steps.semantic.outputs.semantic_release_version

Here's a full example

name: testing outputs

on: push

jobs:
  tester:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@master
      - uses: actions/setup-node@v1

      - uses: codfish/semantic-release-action@testing
        id: semantic
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: test outputs

        # printenv shows OUTPUTS object but NOT JOB_OUTPUTS
        # echo ${{ steps.semantic.outputs.semantic_release_version }} works as expected
        # echo $VERSION works as expected
        run: |
          printenv
          echo ${{ steps.semantic.outputs.semantic_release_version }}
          echo $VERSION # this works
        env:
          VERSION: ${{ steps.semantic.outputs.semantic_release_version }}
          OUTPUTS: ${{ toJson(steps.semantic.outputs) }}
          JOB_OUTPUTS: ${{ toJson(job.steps.semantic.outputs) }}

      # this does NOT work, whether using true or 'true'
      - if: job.steps.semantic.outputs.semantic_release_bool == 'true'
        run: |
          echo "steps.semantic.outputs.semantic_release_bool is true"

      # this actually throws the above error
      - if: steps.semantic.outputs.semantic_release_bool == 'true'
        run: |
          echo "steps.semantic.outputs.semantic_release_bool is true"

      # this does NOT work
      - if: contains(job.steps.semantic.outputs.semantic_release_version, '.')
        run: |
          echo "steps.semantic.outputs.semantic_release_bool is true"

I'm using https://github.com/codfish/semantic-release-action/compare/testing-outputs?expand=1 for testing (tagged with testing).

New to to node, and haven't coded that much in ES5/ES6. But...

core.addPath certainly works in that it's changes to process.env['PATH'] are visible in subsequent steps.

I'm trying to remove some items from the Windows PATH, and also create another env variable. They log fine in the *.js for the action, but subsequent steps are not seeing the changes. But they are seeing changes I've made using core.addPath...

Not sure where to post this...

e.g. ##[error]Error message

We can filter workflows to run on specific branches and also limit the maximum number of jobs that can run simultaneously when using a matrix job strategy.

But I would like to limit concurrent workflows given on given branches or tags filters.

For example:

• Branch develop: Only a single workflow run at a time
• Branch master: Only a single workflow run at a time
• Tag v*: Only a single workflow run at a time

on:
  push:
    max-parallel: 1 # <-----
    branches:    
      - develop
      - master 
    tags:        
      - 'v*'

Or even better, apply the concurrent limit on given steps (i.e. the deployment step, to avoid deployment collisions..).

Note: CircleCI has a similar feature, but its implementation is not great and some people are complaining, see https://discuss.circleci.com/t/prevent-concurrent-builds-of-a-branch/1142 and https://discuss.circleci.com/t/sequentially-running-workflows/23288

I have two different product branches (master & integration) that, as part of their deploy step, perform a deployment to Amazon ElasticBeanstalk. But the deployment fails when another deployment is in-progress.

I’d like the ability to prevent multiple concurrent builds of the same branch, in the same project. The builds would sit “queued” until the running build on that branch completes.

It would be great if it would be possible to define the path event on an arbitrary amount of sub-directories:

on:
  push:
    paths:
      # '*' matches any character except '/'
      - 'sub-project/**'

• Syntax Docs

Currently issueCommand always outputs to stdout here: https://github.com/actions/toolkit/blob/master/packages/core/src/command.ts#L25. This is great but when writing tests for actions it quickly fills up the logs:

> @ test /Users/njero/Code/Examples/example-github-action-typescript
> jest

 PASS  .github/actions/debug-action/__tests__/debug.test.ts
  debug action debug messages
    ✓ outputs a debug message (5ms)

##[debug]👋 Hello! You are an amazing person! 🙌
##[debug]👋 Hello! You are an amazing person! 🙌
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.423s
Ran all test suites.

If the output was wrapped in a call on the Command object itself then it could be mocked in the jest setup. Additionally this might pave the way for alternate logging outputs down the road.

I noticed this repo contains a utility to cache tools. Since my request is somewhat similar, I'm opening this request here:

The docs state that each Job is executed in a fresh environment. In my understanding that means I need to checkout the code, npm install, transpile my code in every job. That seems to be a bit too much overhead for my use case:

I want to migrate my CircleCI setup: https://github.com/fimbullinter/wotan/blob/master/.circleci/config.yml
There's a build job that basically does the checkout, npm install, npm run build and persists the workspace.
build then fans out into multiple parallel test jobs that reuse the workspace of build. These parallel jobs shouldn't be allowed to alter the persisted workspace.
After all test jobs are done I want to run a single (conditional) publish job that also reuses the workspace of build.

CircleCI has two different concepts for that:

• Caches: is independent of the workflow and can for example be used to cache node_modules between workflow runs
• Workspaces: used to share files (e.g. build artifacts) between multiple jobs of the same workflow

I've used this to try and print the steps context:

name: "Info from repo"
on: [pull_request]

jobs:
  obtain-repo:
    runs-on: ubuntu-latest
    steps:
      - name: get-diff
        uses: JJ/github-pr-contains-action@releases/v1
        with:
          github-token: ${{github.token}}
          filesChanged: 1
      - name: dump-steps-test
        env:
          STEPS_CONTEXT: ${{ toJson(steps) }}
        run: echo "$STEPS_CONTEXT"
      - name: obtain-repo
        uses: JJ/repo-in-diff-gh-action@releases/v0
        with:
          diff: ${{steps.get-diff.outputs.diff}}

But it's apparently empty. Any idea?

I'm trying to use the job_id to set an environment variable. For example:

  fedora:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: ./run.sh -c $DIST
      env:
        DIST: ${{ job.id }}

However, it is not working. Overall, I feel that contexts derived from the workflow have very little info, too little to be really useful. This is not the case with event sources.

I used tookit-cache and realized that it was not cached.
Since it is still beta, I would like to know if it will be added in the future or if it is an unknown bug.

I confirmed the same phenomenon in the actions I created, but also in setup-go / setup-node.
The confirmation method is debug log output.
I noticed that the following log was output.

Run actions/setup-node@v1
##[debug]isExplicit: 10.15.0
##[debug]explicit? true
##[debug]checking cache: /opt/hostedtoolcache/node/10.15.0/x64
##[debug]not found
##[debug]Downloading https://nodejs.org/dist/v10.15.0/node-v10.15.0-linux-x64.tar.gz
##[debug]Downloading /home/runner/work/_temp/1d4e5ef4-2f92-4197-9c9f-01b08ce03cef
##[debug]download complete
in/tar xzC /home/runner/work/_temp/c3f24f59-12e4-4e3f-9b9f-57add9676655 -f /home/runner/work/_temp/1d4e5ef4-2f92-4197-9c9f-01b08ce03cef
##[debug]Caching tool node 10.15.0 x64
##[debug]source dir: /home/runner/work/_temp/c3f24f59-12e4-4e3f-9b9f-57add9676655/node-v10.15.0-linux-x64
##[debug]destination /opt/hostedtoolcache/node/10.15.0/x64
##[debug]finished caching tool

Run actions/setup-go@v1
 ##[debug]isExplicit: 1.12.8
##[debug]explicit? true
##[debug]checking cache: /opt/hostedtoolcache/go/1.12.8/x64
##[debug]not found
##[debug]Downloading https://storage.googleapis.com/golang/go1.12.8.linux-amd64.tar.gz
##[debug]Downloading /home/runner/work/_temp/a9ac2dba-8748-44aa-bca0-70e83d9f6064
##[debug]download complete
in/tar xzC /home/runner/work/_temp/f35109b9-3cc5-4da3-ae90-dfd8915a6f45 -f /home/runner/work/_temp/a9ac2dba-8748-44aa-bca0-70e83d9f6064
##[debug]Caching tool go 1.12.8 x64
##[debug]source dir: /home/runner/work/_temp/f35109b9-3cc5-4da3-ae90-dfd8915a6f45/go
##[debug]destination /opt/hostedtoolcache/go/1.12.8/x64
##[debug]finished caching tool

I tried to execute either of them several times, but it was judged not found in the tc.find (https://github.com/actions/toolkit/blob/master/packages/tool-cache/src/tool-cache.ts#L391) part and the download started.

I'm currently using this feature to provide a 'clean' first view of each job/step. See https://github.com/1138-4EB/ghdl/runs/210613754#step:3:46. I think it'd be useful if this was documented Moreover, it'd be really useful to:

• Allow nesting groups.
• Make timing a group a built-in feature. Ideally, show the elapsed time in the same row as the arrows (first/title line of the group), not in the end.
• Print the arrows (expand/collapse) in the margin, not in the body. And add vertical indentation lines.

I don't know if any of these features is available already through some other keyword.

Ref #98

I copied the JavaScript template over to a private repository and then added the action to another repo: - uses: aai/cache@v1.

This is the log output:

Download action repository 'aai/cache@v1'
##[warning]Failed to download action 'https://api.github.com/repos/aai/cache/tarball/v1'. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 27.679 seconds before retry.
##[warning]Failed to download action 'https://api.github.com/repos/aai/cache/tarball/v1'. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 14.294 seconds before retry.
##[error]Response status code does not indicate success: 404 (Not Found).

Choosing a location for your action only covers using public repositories for GitHub Actions, or putting the action in the repository using the action. So I'm not surprised what I'm trying to do didn't work, but I'm wondering if there are any plans to support this use case?

In the doc for the toolkit the versioning scheme for Javascript actions has examples like v1. Curious why not use semantic versioning and put forward examples like `1.0.3. Is there a technical limitation? Actions are critical dependencies just like packages on which people depend. Would be great to use a familiar versioning approach.

I just got a PR from dependabot bumping @actions/github to version 1.0.1 but there doesn't seem to be release notes for this in the project folder, or a release/tag. Is there an easier way to see what changed than looking through the commits?

Would be helpful to have a schema/explanation of what matchers actually do.

The https://github.com/actions/upload-artifact repo action.yml contains the following:

https://github.com/actions/upload-artifact/blob/ec188c28d23c831d7283eb4280a4490eb5010092/action.yml#L11-L12

name: 'Upload artifact'
description: 'Publish files as workflow artifacts'
author: 'GitHub'
inputs: 
  name:
    description: 'Artifact name'
    required: true
  path:
    description: 'Directory containing files to upload'
    required: true
runs:
  plugin: 'publish'

So this leaves me to ask, what other things apart from running NodeJS & Docker Image/Container can we do as Action developers as mentioned in the documentation here - https://help.github.com/en/articles/metadata-syntax-for-github-actions#runs

/cc @chrispat & @damccorm

I'm following instructions in the walk-through, but I get:

Download action repository 'JJ/testing-actions@releases/v1'
##[warning]Failed to download action 'https://api.github.com/repos/JJ/testing-actions/tarball/releases/v1'. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 15.233 seconds before retry.
##[warning]Failed to download action 'https://api.github.com/repos/JJ/testing-actions/tarball/releases/v1'. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 13.093 seconds before retry.

The documentation gives the impression that you just need to push to master.

It looks like the tarball is created automatically for the branch; but the step of uploading (through push -u origin) is not mentioned explicitly either.

From a user's perspective many of the packages are clear: actions/io, actions/exec, actions/tool-cache. But toolkit and core both offer core functionality (setting results, logging etc). It seems odd that a user adds toolkit and core. How do we explain how they differ other than origins?

toolkit has redundant exit while there's an exit package.

We should decide whether the core functionality is in the toolkit package (named after the whole repo) or they merge into core (where most of the other core functionality is).

Some start with 0.x and some start with 1.x. Let's get consistent and then update all the setup tasks to consume the new versions.

I haven't seen any tests or examples that show how you'd mock @actions/github using Jest. How would one go about doing this?

My action contains the following:

import { getInput } from "@actions/core";
import { context, GitHub } from "@actions/github";

const client = new GitHub(
  getInput("repo-token", { required: true })
);

var actorAccess: Octokit.Response<CollaboratorPermissionLevel> = await this.client.repos.getCollaboratorPermissionLevel({
  ...context.repo,
  username: context.actor
});

// ...

await this.client.reactions.createForIssueComment({
  ...context.repo,
  comment_id: commentId,
  content: this.reaction.type,
});

Hey folks! I wanted to suggest some improvements to the README for this repo, to help folks get started using the toolkit. I can open a PR, but it may take some time to find the bandwidth to do it right - so in the meantime, below is a proposed outline.

Goals

• Clarify the different packages
  • What each one is, why they're separate
• Show examples of common tasks (ie: reading from the event payload, accessing an input)
• Make the entrypoint for the repo more _action_able.

Outline

No content suggestions for the first bit:

• Awesome logo
• Description: "The GitHub Actions Toolkit provides a set of packages to make creating actions easier and drive consistency."
• Packages (the existing table)

Then, a smaller link to the JS template:

Get started with the javascript-template!

• Usage

When viewing the README, I think we need to show more detail about using the toolkit. I realize that because its mixed between different packages, usage will vary - but showing is better than telling for tools like this. A rough outline of what those examples could be:

Get an input from the workflow

Using the @actions/core library, we can interact directly with the Actions runtime to access logging, workflow inputs and set outputs.

steps:
  - uses: actions/hello-world
    with:
      name: octocat

const core = require('@actions/core')
const name = core.getInput('name')
console.log(`Hello ${name}!`)

Read from the event payload

const { context } = require('@actions/github')
console.log(context.payload)

Make an API request to GitHub

const { GitHub } = require('@actions/github')
const octokit = new GitHub(process.env.GITHUB_TOKEN)
await octokit.issues.create({
  title: 'Example',
  owner: context.repo.owner,
  repo: context.repo.repo
})

Run a JavaScript file in the repo

const file = `${process.env.GITHUB_WORKSPACE}/index.js`
await exec.exec(`node ${file}`)

Note that all of those examples are in JavaScript, not TypeScript. I think its important to show that TS isn't necessary, and given the need to check in the compiled JS files (which I realize y'all are working to improve on), I think it'll really help make the toolkit feel more approachable.

Continuing with the outline!

• Appendix

This would include all of the very helpful doc links at the bottom of the current README.

These are all suggestions - y'all can take or leave all or none 😄 If I can open a PR I will, but please feel free to implement them.

cc @chrispat

Currently for the @actions/github this library extends @octokit/rest's Octokit class and in the super call assumes that the authentication is a standard token. (code link)

Other authentication methods should be valid here as well.

Hello!

I'm trying to follow along in javascript-action.md, which has several code examples. Specifically, lines 19-22 and 46-58.

I'd love to use these examples, except for me (as a first-time Action author) it's entirely unclear where they're supposed to go.

Clarifying that inside of the document would be ideal.

I have two actions that create annotations after running eslint & stylelint but I have yet to move them to v2. They run fine in v2 workflows though and annotations are created as you'd expect.

I'm trying to setup a new action that creates annotations just like my other actions but using the toolkit packages. I'm able to create a checks run using GITHUB_TOKEN and the github client, but I'm not able to call the update checks function with the annotations. I keep getting a 422 response back. Are there differences between v1 and v2 actions that would prevent this from working?

This call works:

const githubClient = new github.GitHub(core.getInput("repo-token", { required: true }));

const { data } = await githubClient.checks.create({
  ...github.context.repo,
  name: github.context.action,
  head_sha: github.context.sha,
  started_at: new Date().toISOString(),
});

But this call doesn't:

const githubClient = new github.GitHub(core.getInput("repo-token", { required: true }));

const { data} = await githubClient.checks.update({
  ...github.context.repo,
  check_run_id: id, // data.id from the first call
  completed_at: new Date().toISOString(),
  conclusion: conclusion,
  output,
  status: "completed",
});

👋 Noticing there is some differences between the published 1.0.0 versions of the packages that are published on npm and the code in master. One specific thing was the features added on #49

Currently working around this with a fork of just the tool-cache package so I can test a matrix build of an action I'm working on.

Would be awesome if we can get publishes on merges to master (or some other awesomeness) 🎉 ❤️

I'm working on an action that triggers on issue_comment and was wondering if there's a way to get ahold of the feature branch from which the comment originated?

I'm currently using github.context.repo.owner and github.context.repo.repo to access the repo and its owner names but would need a branch name as well.

We're changing the syntax on the runner and need to update in core here (and elsewhere we need to update to consume the new version).

getInput function in @actions/core package only replaces the first occurrence of a "space" character.

e.g. 'require some value' will be transformed to 'INPUT_REQUIRE_SOME VALUE' which is wrong.

export function getInput(name: string, options?: InputOptions): string {
  const val: string =
    process.env[`INPUT_${name.replace(' ', '_').toUpperCase()}`] || ''
  if (options && options.required && !val) {
    throw new Error(`Input required and not supplied: ${name}`)
  }
/* ... */

Following line

process.env[`INPUT_${name.replace(/ /g, '_').toUpperCase()}`] || ''