feat!: step status reporting + fix pull request context overwrite bug

[ecrupper]

Closes go-vela/community#958

Adding the following lines to scm.Status(...):

	// only report opened, synchronize, and reopened action types for pull_request events
	if strings.EqualFold(b.GetEvent(), constants.EventPull) && !strings.EqualFold(b.GetEventAction(), constants.ActionOpened) &&
		!strings.EqualFold(b.GetEventAction(), constants.ActionSynchronize) && !strings.EqualFold(b.GetEventAction(), constants.ActionReopened) {
		return nil
	}

This will prevent any overwrites of the "core" pull_request event. Perhaps this can be a candidate for revisiting if we cut over to a version: "2" pipeline implementation, but the expectation of our users is that webhook events report to their respective contexts to the SCM. Therefore the behavior of continuous-integration/vela/pull_request should remain unchanged.

Closes go-vela/community#576

In order to still grant status reporting for "non-core" action types, opening the door for step reporting seemed like the right approach. With this change, steps with report_as defined will post their status to the defined context. It will be prefixed by the standard event prefix. For example:

  # validate title of PR on open or edit
  - name: validate title
    image: alpine:latest
    report_as: title-validator
    ruleset:
      event: [ pull_request:opened, pull_request:reopened, pull_request:edited ]
    commands:
      echo $VELA_BUILD_MESSAGE | grep -Eq "Expectation" && exit 0 || exit 1

This step will create and update a commit status with the context continuous-integration/vela/pull_request/title-validator.

The limitations I decided to impose are:

1. Limit of 10 custom statuses per pipeline. This prevents SCM API abuse + approaching of the 1000 limit for status updates on a single commit.
2. No reporting to the same context. This can only lead to problems and unexpected behavior.

Question I had: should a skipped step be a success?

[codecov]

Codecov Report

Attention: Patch coverage is 55.43478% with 41 lines in your changes are missing coverage. Please review.

Project coverage is 63.24%. Comparing base (8a5955d) to head (4bc0606).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1090      +/-   ##
==========================================
+ Coverage   63.12%   63.24%   +0.11%     
==========================================
  Files         348      348              
  Lines       10533    10594      +61     
==========================================
+ Hits         6649     6700      +51     
- Misses       3400     3409       +9     
- Partials      484      485       +1     

Files	Coverage Δ
compiler/native/validate.go	97.29% <100.00%> (+0.37%)	⬆️
database/step/table.go	100.00% <ø> (ø)
mock/server/step.go	0.00% <ø> (ø)
api/build/restart.go	0.00% <0.00%> (ø)
api/build/plan.go	0.00% <0.00%> (ø)
api/build/create.go	0.00% <0.00%> (ø)
scm/github/repo.go	76.40% <84.00%> (+1.24%)	⬆️
api/build/compile_publish.go	0.00% <0.00%> (ø)

[plyr4]

nice

[plyr4]

Question I had: should a skipped step be a success?

in my opinion i dont think so, that might make required status checks auto pass when it never ran

[KellyMerrick]

lgtm

[JordanSussman]

@ecrupper do you think it makes sense to open up another community issue for expanding this functionality to work with stages?

[ecrupper]

@ecrupper do you think it makes sense to open up another community issue for expanding this functionality to work with stages?

Definitely. Also somewhat related would be go-vela/community#910 with the idea of a "status" for a stage.