Currently, the client can set a configuration option in GWY CI Pipeline to allow clients to still merge their PRs even if issues were found. Let's say there is some time constraint to release a version, and it exists in the code some known issue an action is detecting and client still wants to be able to apply the action in the CI, possibly detecting other unknown issues, and not get its entire development cycle interrupted until the known issue is fixed.
Client can rely on this configuration option then to apply the CI, get its detailed report and decide if it wants or not to merge the PR after seeing what the CI found.
The issue, mainly a cosmetic one, is that the CI is relying on exiting either with 1 or 0, to either allow or not the PR merge (exit 0 allows, exit 1 blocks PR merge). This approach, apart from allowing or not PR merges, also sets the CI result red / green indicators, masquerading a CI run to green when it finds errors if this option to allow merges on errors is enabled.
The scope of this ticket is to change the approach we use to block or not PR merges on failure. Instead of relying on exit code, using github API and setting directly the target PR merge status, no matter its exit code (exit code will determine if passed or not, github API call will still enable or disable the ability to merge the PRs, no matter its result).
Following is a sample snippet of an API call for the enhancement:
echo "All good, merge allowed"
gh api -X POST \
-H "Accept: application/vnd.github+json" \
"/repos/${{ github.repository }}/statuses/${{ github.sha }}" \
-f state=success \
-f context="merge-control" \
-f description="CI passed, merge allowed"
Currently, the client can set a configuration option in GWY CI Pipeline to allow clients to still merge their PRs even if issues were found. Let's say there is some time constraint to release a version, and it exists in the code some known issue an action is detecting and client still wants to be able to apply the action in the CI, possibly detecting other unknown issues, and not get its entire development cycle interrupted until the known issue is fixed.
Client can rely on this configuration option then to apply the CI, get its detailed report and decide if it wants or not to merge the PR after seeing what the CI found.
The issue, mainly a cosmetic one, is that the CI is relying on exiting either with 1 or 0, to either allow or not the PR merge (exit 0 allows, exit 1 blocks PR merge). This approach, apart from allowing or not PR merges, also sets the CI result red / green indicators, masquerading a CI run to green when it finds errors if this option to allow merges on errors is enabled.
The scope of this ticket is to change the approach we use to block or not PR merges on failure. Instead of relying on exit code, using github API and setting directly the target PR merge status, no matter its exit code (exit code will determine if passed or not, github API call will still enable or disable the ability to merge the PRs, no matter its result).
Following is a sample snippet of an API call for the enhancement: