feature: custom fields support

[leonsteinhaeuser]

Closes: #22

The following example workflow assumes that your project has following fields defined (non default):

Field name	Type	Options	Description
Priority	Text		Allows you to define any value for this field
Severity	Text		Allows you to define any value for this field
Number	Number		Allows you to define any number for this field
Date	Date		Allows you to define a date (dd-mm-yyyy) for this field
Single Select	Single Select	Option 1, Option 2, Option 3	Allows you to select a value from X options
Iteration	Iteration	Iteration 1, Iteration 2, Iteration 3	Allows you to select a value from X options

For more checkout the README

name: Project automations (user)

on:
  issues:
    types:
      - opened
      - reopened
  pull_request:
    types:
      - opened
      - reopened

env:
  gh_project_token: ${{ secrets.PROJECT_PERMISSION_TOKEN }}
  project_id: <project-id>
  gh_username: <username>
  status_todo: "Todo"
  custom_field_values: '[{\"name\": \"Priority\",\"type\": \"text\",\"value\": \"uuid1\"},{\"name\": \"Number\",\"type\": \"number\",\"value\": \"100\"},{\"name\": \"Date\",\"type\": \"date\",\"value\": \"2022-01-28T20:02:27.306+01:00\"},{\"name\": \"Single Select\",\"type\": \"single_select\",\"value\": \"Option 1\"},{\"name\": \"Iteration\",\"type\": \"iteration\",\"value\": \"Iteration 1\"}]'

jobs:
  issue_opened:
    name: issue_opened
    runs-on: ubuntu-latest
    if: github.event_name == 'issues' && github.event.action == 'opened'
    steps:
      - name: 'Move issue to ${{ env.status_todo }}'
        uses: leonsteinhaeuser/project-beta-automations@v1.1.0-alpha.1
        env:
          DEBUG_LOG: "true"
        with:
          gh_token: ${{ env.gh_project_token }}
          user: ${{ env.gh_username }}
          project_id: ${{ env.project_id }}
          resource_node_id: ${{ github.event.issue.node_id }}
          status_value: ${{ env.status_todo }}

  update_issue_custom_fields:
    name: update_issue_custom_fields
    runs-on: ubuntu-latest
    needs:
      - issue_opened_or_reopened
    steps:
      - name: 'Modify custom fields'
        uses: leonsteinhaeuser/project-beta-automations@v1.1.0-alpha.1
        env:
          DEBUG_LOG: "true"
        with:
          gh_token: ${{ env.gh_project_token }}
          user: ${{ env.gh_username }}
          project_id: ${{ env.project_id }}
          resource_node_id: ${{ github.event.issue.node_id }}
          operation_mode: custom_field
          custom_field_values: ${{ env.custom_field_values }}

[zoebosschaart]

Two minor comments. As far as I can see, it looks good. However, I only can actually test when the version is released.

[zoebosschaart]

Is it possible to use both? So that you can use in operation mode 'custom_field', also a status change. Example: when an issue is created, it will be added to project x in status, todo. but also with iteration x.

[leonsteinhaeuser]

You can define either custom_field or status mode, but not both at the same time. If you want to define both at once, you can simply define that change within the json (as single select). Otherwise, you can also define two separate steps:

• Change status
• Change of the custom field

[zoebosschaart]

I think a typo: nil = null?

[leonsteinhaeuser]

It depends on the language. For example, in Go there is no null, but instead you use nil. To clarify this for more users, I think you are right that this should be changed.

[nddery]

Haven't been able to test this out but from the face of the code, it looks good to me.

I wonder if it would be nice to fold status, operation_mode, and custom_field_values into a single field ? Currently, using custom_field_values one can set the status - if we were to provide a default for type (to single_select_field maybe), it would make it using the custom field simpler (this would be a breaking change, hence maybe it's not a good path forward).

[nddery]

If this defaults to status, should it be non-required ? Being not-required would also make the next release not a breaking one, as far as I'm aware.

[leonsteinhaeuser]

My understanding of the action definition is that it should not be necessary to specify the value if the default option is pre-filled. The snippet from below defines this field.

  operation_mode:
    description: |
      Specifies the operation mode. 
      The value must be of type string.
      The value can be one of the following:
      - custom_field
      - status
    required: true
    default: "status"

Since this ** required ** setting is not required when a default value is specified, I think you are right that we do not need to make this field required.

[leonsteinhaeuser]

Do you have a blocker that prevents this function from being merged? Otherwise, I would like to merge this feature over the weekend.

[zoebosschaart]

Do you have a blocker that prevents this function from being merged? Otherwise, I would like to merge this feature over the weekend.

For me not, I really would like the merge so that i can use the new functionality on monday!

[nddery]

Same, looking forward to using this new functionality!