See this action run. It logs the full event payload and has debugging enabled:

https://github.com/gr2m/helpdesk/runs/3255305558?check_suite_focus=true

I seems as if the values are parsed as part of the title? Maybe the problem is that the line breaks are \r\ns instead of just \ns?

To reproduce:

1. create an issue form with a text input
2. create an issue using the form and put some ' or ()
3. in your workflow, run echo '${{ steps.issue-parser.outputs.jsonString }}' > form_submitted.json

Failed job: https://github.com/TestGTR/website/runs/8229050530?check_suite_focus=true

When the action is pinned to a full SHA of a release (as recommended in https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions) it fails with

2022-06-23T14:25:16.5848216Z ##[group]Run stefanbuck/github-issue-parser@fb73b92b5c4d283c3e9a198f2bb7dbbf6cf87079
2022-06-23T14:25:16.5848597Z with:
2022-06-23T14:25:16.5848885Z   template-path: .github/ISSUE_TEMPLATE/bug_report.yml
2022-06-23T14:25:16.5849185Z ##[endgroup]
2022-06-23T14:25:16.5973472Z ##[error]File not found: '/home/runner/work/_actions/stefanbuck/github-issue-parser/fb73b92b5c4d283c3e9a198f2bb7dbbf6cf87079/dist/index.js'
2022-06-23T14:25:16.6046545Z Post job cleanup.

To get it around it was pinned to fc06b2a. It kind of works but it isn't compatible with Dependabot in the sense that it can't update the action automatically because it follows releases usually.

cc @jamacku

So we know that v3 had some changes around parsing checkboxes (now parsed as arrays), which is nice. Thank you!
However, we have been using v2 for quite some time without any issues. We explicitly specify v2 to make sure new updates don't get automatically promoted without testing.
However, we noticed that although we use v2, the action parses checkboxes the new way, which caused our code to fail until we adjusted it to handle the new output format. We started to see this issue (i.e. checkboxes parsed as arrays) exactly 7 days ago (10/26/22). All forms submitted before that date with same code worked fine and checkboxes appear to be parsed the old way. Again, despite the confusion this has caused and the time it took us to get to the the bottom of the issue (the error message is so unhelpful) we got the issue fixed for the time being by updating the code to expect arrays (although we still use v2). However, we are so curious to know how would this update possibly affect older versions. (v2 in our case)

Usage:

- uses: stefanbuck/github-issue-parser@v2

Error message:

System error: SyntaxError: Unexpected token u in JSON at position 0<

See: #47 (comment)

For some odd reason the release pipeline was using an older commit as a baseline and this resulted in another 3.0.0 release ergo the pipeline failed with tag 'v3.0.0' already exists. I created the release manual for now, but the same happened earlier before as well see #43 (comment) @gr2m do you have any idea what is causing this?

Given this is happening since #39 it must be related to this change. Is there another way to address #23?

cc @stefanbuck @gr2m

Somethings wrong with the semantic-release workflow, I'm having a look into it

I would like to parse checkboxes entries and store them in an array.

I currently have an issue form containing this snippet 👇

  - type: checkboxes
    id: fav_frameworks
    attributes:
      label:  What are your favourite frameworks ?
      options:
        - label: React.js
        - label: jQuery
        - label: Express
        - label: Angular
        - label: Vue.js
        - label: ASP.NET Core
        - label: Flask
        - label: ASP.NET
        - label: Django
        - label: Spring
        - label: Angular.js
        - label: Laravel
        - label: Ruby on Rails
        - label: Gatsby
        - label: FastAPI
        - label: Symfony
        - label: Svelte
        - label: Drupal

And would like the output to be similar to:

{
    "fav_frameworks": ["Laravel", "Svelte"]
}

The current behaviour would produces this:

 {
    "laravel": true,
    "svelte": true,
 }

All the examples including https://github.com/stefanbuck/github-issue-parser#setup and https://github.com/stefanbuck/ristorante/blob/main/.github/workflows/order.yml contain

- run: echo '${{ steps.issue-parser.outputs.jsonString }}'

and it can be used to run arbitrary code with full access to repositories unless permissions are restricted explicitly. For example in evverx/ristorante#2 "Number of Pizza's": '$(date)' led to

2022-06-23T19:34:30.4915792Z shell: /usr/bin/bash -e {0}
2022-06-23T19:34:30.4916018Z ##[endgroup]
2022-06-23T19:34:30.5006883Z {
2022-06-23T19:34:30.5007522Z   "flavour": "Veg Tikka",
2022-06-23T19:34:30.5008735Z   "size": "Small",
2022-06-23T19:34:30.5008978Z   "toppings": "Tomato",
2022-06-23T19:34:30.5009299Z   "count": "Thu Jun 23 19:34:30 UTC 2022",
2022-06-23T19:34:30.5009513Z   "confirm": true
2022-06-23T19:34:30.5009712Z }

cc @jamacku

Blank JSON Response

Hi there! I have been having one heck of a time getting this Action working. I have made several JS Actions in the past and tried to debug what was going on by forking the repo but this section is proving to be quite troublesome.

The Issue

When running the Action against this issue template, the JSON response in blank.

It should be noted that I am running this Action in a slightly different context. I am running an workflow dispatch model where a person comments /approve on an issue that was generated from an issue template. From here, the workflow dispatch feeds the issue body into the Action where it then parses issue.body

More Context

At first, I tried modifying the contents of the file present at $GITHUB_EVENT_PATH to get my issue.body content into the Action. This proved to be troublesome, so I just forked the Action and provided a string as another input option for the issue.body

I also added a lot of debug lines to try and troubleshoot why this Action just out the JSON as I would expect.

I even added a jest test to my fork of the Action which tests my exact workflow and it seems to work just fine

Replicating the Issue

The following workflow is where I am experiencing the issue - link

1. I get the issue body from the workflow dispatch context and pass it into my fork of this Action
2. My fork of the Action correctly reads in the issue body and issue template
3. The id-mapping looks correct
4. 👀 The result variable looks pretty botched...
5. The json output is empty 😢

• Link to my workflow
• Link to my fork of the Action
• Link to my testing issue
• Link to my issue template

Example issue:
gr2m/github-issue-parser-test#1

Parse run:
https://github.com/gr2m/github-issue-parser-test/runs/3576748802?check_suite_focus=true

Output:

{
  "my_textarea_input": "1st paragraph"
}

Expected output:

{
  "my_textarea_input": "1st paragraph\n\n2nd paragraph"
}

I can look into it tomorrow

When creating a blank issue with only the headline and empty body, github-issue-parser tracebacks.

Example issue: - jamacku/systemd#29
Example action run: - https://github.com/jamacku/systemd/runs/8070557950?check_suite_focus=true#step:3:1

(node:1642) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'trim' of null
    at run (/home/runner/work/_actions/stefanbuck/github-issue-parser/fc06b2a0adc5ccb7702ab6b641fd8a742a5e9cc0/dist/index.js:76:6)
    at Object.932 (/home/runner/work/_actions/stefanbuck/github-issue-parser/fc06b2a0adc5ccb7702ab6b641fd8a742a5e9cc0/dist/index.js:135:3)
    at __nccwpck_require__ (/home/runner/work/_actions/stefanbuck/github-issue-parser/fc06b2a0adc5ccb7702ab6b641fd8a742a5e9cc0/dist/index.js:4803:43)
    at /home/runner/work/_actions/stefanbuck/github-issue-parser/fc06b2a0adc5ccb7702ab6b641fd8a742a5e9cc0/dist/index.js:4821:37
    at Object.<anonymous> (/home/runner/work/_actions/stefanbuck/github-issue-parser/fc06b2a0adc5ccb7702ab6b641fd8a742a5e9cc0/dist/index.js:4824:12)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
(node:1642) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:1642) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Hi Stefan!

I use your action for my automation at https://github.com/gr2m/helpdesk and made another show about it: gr2m/helpdesk#42

One problem I realized is that all values seem to be lowercased. Is that intentional?

https://github.com/stefanbuck/github-issue-parser/releases/tag/v3.0.0

The reasoning for script injection makes sense, but I'm curious as to why not bake ${{ github.event.issue.body }} in as a default in the action?

Like:

  issue-body:
    required: true
    description: 'Issue body to parse'
+   default: ${{ github.event.issue.body }}

When a user reports an issue using the empty issue button, github-issue-parser will parse the result without taking into consideration issue form template passed as input.

As shown here: systemd/systemd#23968 (comment)

It would be great if github-issue-parser could check if the reported issue match provided the issue form template.

This has been caused by my change in #3. I'll create a follow up PR for this

I have realised that this action doesn't work in windows. I get the following error:

(node:6056) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'undefined/issue-parser-result.json'
    at Object.openSync (fs.js:462:3)
    at Object.writeFileSync (fs.js:1384:35)
    at run (D:\a\_actions\stefanbuck\github-issue-parser\v2\dist\index.js:121:6)
    at Object.932 (D:\a\_actions\stefanbuck\github-issue-parser\v2\dist\index.js:135:3)
    at __nccwpck_require__ (D:\a\_actions\stefanbuck\github-issue-parser\v2\dist\index.js:4803:43)
    at D:\a\_actions\stefanbuck\github-issue-parser\v2\dist\index.js:4821:37
    at Object.<anonymous> (D:\a\_actions\stefanbuck\github-issue-parser\v2\dist\index.js:4824:12)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
(node:6056) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:6056) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I think it is because env.HOME is not defined in Windows.

If using this in a private repository, we have to use the markdown issue templates vs. issue forms that's in beta only for public repositories.

If we have a markdown response that doesn't have new lines between the heading and response, it returns as an empty JSON response {}. An example of is below:

### Repo name
repo-name

### team
team-name

If we ensure that there are spaces before the question/answer, then it works. Like so:

### Repo name

repo-name

### team

team-name