Parse
- Alpha
When a new issue is opened, before any action can be taken on it, you should
parse its contents and turn it into a machine-readable format. The
issue-ops/parser
action does this by
comparing the body of the issue with the original issue form template. This way,
you can directly reference issue form fields without having to parse the body
yourself with regular expressions. This action provides specific output formats
based on the type
property of the input.
Input type | Example parsed output |
---|---|
input | "octorepo" |
textarea | "This is a description!\n\nIt is multiline, too!" |
dropdown | ["octocat", "issueops"] |
checkboxes | { "selected": ["Yes"], "unselected": ["No"] } |
Depending on how you're processing the input data, different types may be more
helpful than others! Based on the issue form template and the contents of the
issue itself, the json
output will look similar to the following:
{"the_name_of_the_thing": "this-thing","the_nickname_of_the_thing": "thing","the_color_of_the_thing": ["blue"],"the_shape_of_the_thing": ["square"],"the_sounds_of_the_thing": ["re", "mi"],"the_topics_about_the_thing": [],"the_description_of_the_thing": "This is a description.\n\nIt has lines.","the_notes_about_the_thing": "- Note\n- Another note\n- Lots of notes","the_code_of_the_thing": "const thing = new Thing()\n\nthing.doThing()","the_string_method_of_the_code_of_the_thing": "thing.toString()","is_the_thing_a_thing": {"selected": ["Yes"],"unselected": ["No"]},"is_the_thing_useful": {"selected": ["Sometimes"],"unselected": ["Yes", "No"]},"read_team": "IssueOps-Demo-Readers","write_team": "IssueOps-Demo-Writers"}
Once an issue has been parsed, the next step is to validate the contents to make sure the request isn't missing data, doesn't contain invalid data, and can be processed by your workflow.
The new repository worklow starts off with the following issue form template.
name: New Repository Requestdescription: Submit a request to create a new GitHub repositorytitle: '[Request] New Repository'labels:- issueops:new-repositorybody:- type: markdownattributes:value:Welcome to GitHub! Please fill out the information below to request anew repository. Once submitted, your request will be reviewed by theIssueOps team. If approved, the repository will be created and you willbe notified via a comment on this issue.- type: inputid: nameattributes:label: Repository Namedescription: The name of the repository you would like to create.placeholder: octorepovalidations:required: true- type: dropdownid: visibilityattributes:label: Repository Visibilitydescription: The visibility of the repository.multiple: falseoptions:- private- publicvalidations:required: true- type: inputid: read-teamattributes:label: Read Teamdescription: The GitHub Team that will get read access to the repository.placeholder: octocat-readersvalidations:required: true- type: inputid: write-teamattributes:label: Write Teamdescription: The GitHub Team that will get write access to the repository.placeholder: octocat-writersvalidations:required: true- type: dropdownid: auto-initattributes:label: Auto Initdescription: Select `true` to initialize the repository with a `README`.multiple: falseoptions:- 'true'- 'false'validations:required: true- type: textareaid: topicsattributes:label: Topicsdescription:(Optional) A list of topics to add to the repository. Separate eachtopic with a new line.placeholder: |octocatoctodogvalidations:required: false
When a user submits a request for a new repository, the issue form will look something like this:
Creating an issue will kick off the start of the IssueOps process. However, in order to do anything with the request, we need to parse the issue body and extract the information we need to get approval and create a repository.
name: Issue Opened/Edited/Reopened# At minimum, the issue body should be parsed any time an issue is opened,# edited, or reopened. This ensures that the most up to date information is# validated.on:issues:types:- opened- edited- reopenedjobs:# Different request types may have different inputs. For example, a new# repository request may have different inputs than a repository transfer# request. You can create multiple jobs to parse different types of requests# in the same workflow. Labels can be used to control which jobs run for# which types of requests.new-repository-request:name: New Repository Requestruns-on: ubuntu-latest# Assign labels for different types of requests, and use those labels to# trigger different workflows, jobs, and steps.if: contains(github.event.issue.labels.*.name, 'issueops:new-repository')# Initially, this workflow only needs permissions to read issues and# contents. This will be expanded later as we build additional# functionality.permissions:contents: readissues: readsteps:# Get the repository contents. This lets the workflow reference files in# the repository such as the issue form template.- name: Checkoutid: checkoutuses: actions/checkout@vX.X.X- name: Parse Issueid: parseuses: issue-ops/parser@vX.X.Xwith:body: ${{ github.event.issue.body }}issue-form-template: new-repository-request.yml- name: Output the Parsed Issueid: outputrun: echo ${{ steps.parse.outputs.json }}
At this point, our issue has successfully transitioned into the Parsed
state.
This means that we have a machine-readable representation of the request that
can be further processed by our workflows. However, we don't know if the request
actually contains valid information! The next transition involves validating the
parsed request against a set of rules to make sure it's ready to be processed.