Add 'payload' field to allow for Repository Dispatch

[peckjon]

Currently, actions/add-to-project cannot be used via repository_dispatch (or workflow_dispatch) since it retrieves all event-related information from the immediate github context, which is distinct from the dispatching workflow context.

This PR adds the ability to pass relevant context information from a dispatching workflow to a target workflow, and provides relevant documentation & code samples.

[omerbensaadon]

Hey Jon! We would welcome this addition!

Do you mind adding some tests? I'll leave you some comments on the documentation

[omerbensaadon]

Requested a few changes docs-wise and adding some tests wouldn't hurt!

[peckjon]

Thanks @omerbensaadon ! Changes to README completed.

I'm not aware of a way to add a test using Repository Dispatch, since it takes flow control away from the current environment 😞

[mattcosta7]

Suggested change

	const payload = core.getInput('payload') ? JSON.parse(core.getInput('payload')) : github.context.payload
	const inputPayload = core.getInput('payload')
	cont payload = inputPayload ? JSON.parse(inputPayload) : github.context.payload

[mattcosta7]

Thanks @omerbensaadon ! Changes to README completed.

I'm not aware of a way to add a test using Repository Dispatch, since it takes flow control away from the current environment 😞

For the test here, I think it's ok to just test that side of the workflow changes.

Particularly we might add a new test that calls mockGetInput with the new 'payload' mock as well

a sample of other input mocks is here:

add-to-project/__tests__/add-to-project.test.ts

Lines 14 to 17 in ce05fa3

	mockGetInput({
	'project-url': 'https://github.com/orgs/actions/projects/1',
	'github-token': 'gh_token',
	})

that should at least validate that the code accepts a payload as input

[jon-nfc]

is this going to be merged?

This feature is a must for workflow_run triggers and will also enable a workaround for the action not working on fork repositories. see nofusscomputing/action_project#3.

This PR would offer a workaround for #163 and #189