Parse event path file to enable reduced CI mode

[smvv]

Changes

• Detect github event name from event path file.
• Use detected event name to enable reduced CI mode (if not explicitly set).
• Refactor some test file paths.

Detect GitHub event type

The environment variable GITHUB_EVENT_NAME is missing inside a reusable workflow file. We can use the github event path file to derive this event name value.

The event path file is the path to the file on the runner that contains the full event webhook payload. For example, /github/workflow/event.json.

If the environment variable GITHUB_EVENT_PATH is missing, the detected event type becomes unknown.

If the key pull_request is found in the github event path file, the detected event type becomes pull_request.

Else, if the key ref is found in the github event path file, the detected event type becomes push.

Enable reduced CI mode if auto and PR

When the initial reduced CI mode is auto or empty, and the detected event type is pull_request, change the reduced CI mode to enabled.

CLI log messages

I added a simple console log handler that help diagnosing what values changed.

For example, locally, I see these messages:

13:54 INF GITHUB_EVENT_PATH is not set so event type is unknown
13:54 INF Detected GitHub event type event_type=unknown

because the event path is missing and thus event_type becomes unknown.

In CI, I can see these messages for this pull request:

12:36 INF Using GitHub event payload file event_path=/home/runner/work/_temp/_github_workflow/event.json
12:36 INF Detected GitHub event type event_type=pull_request
12:36 INF Enabled reduced CI mode for pull_request event when mode is auto

[carlopi]

I think the logic here it's a bit too simple.

I would prefer either to remove the

	if _, ok := payload["ref"]; ok {
		return githubEventPush, nil
	}

section, since that not used AND looks wrong to me (I guess ref it's present in more cases that a push).

More in general, could you compile a list of different situation where this code might be reached? And then we can map what default behaviour we would like to see in the different situations?

[carlopi]

Thanks!

There are a couple of things that would be handy to clean-up before going live:

• fixup TestCITools
• discuss detection of events (in particular detection of push)
• discuss how to be more robust to unseen changes in webhook (more e2e test)