Build: Allow to skip/cancel builds successfully

[mateuszkocz]

Which problem is this feature request solving?

Hello. I've been experimenting with a plugin that would allow builds to be cancelled prematurely, based on some "smart" logic. Something akin to build.ignore but with a plugin instead.

Currently, in order to cancel a build one needs to use utils.build.cancelBuild. According to the docs, it "indicate[s] that the build is being cancelled as planned". Unfortunately, the Netlify's integration on GitHub doesn't consider this action to be "as planned" and reports a failure, making it impossible to proceed with PRs not meant to be built.

PR with this behaviour.

Describe the solution you'd like

It would be great if the cancelBuild reported an "ok" to GitHub allowing the skipped PRs to be merged, or if there was another function available to implement this kind of behaviour (like utils.build.skipBuild).

Describe alternatives you've considered

I tried to use build.ignore in netlify.toml and see what happens, but was unsuccessful in triggering the ignoring behaviour, so I can't properly examine how that scenario would work. 🙈

Can you submit a pull request?

~Yes~/No. (I don't know much about what's going on in here. 😔)

[ehmicky]

Thanks for reporting this @mateuszkocz

@kitop @keiko713 cancelBuild() calls the cancelSiteDeploy endpoint. Shouldn't that endpoint result in successful GitHub PR statuses?

[keiko713]

Thanks for the report, @mateuszkocz !

Canceling build/deploy is treated as "failed deploy", therefore it'll result failed in GH PR status.

I'd say that we want to treat this as failed deploy, since lots of sites are using this deploy process as CI/CD and I would feel wrong to say "success" there without successfully finishing it (aka aborted in the middle).

However, maybe we could report it as neutral state (not success nor failed), which what we are actually doing when the build.ignore setting is triggered. Not sure if we want to do it as "default", or we want to do it "only under certain condition" though. Thoughts @kitop ?

[kitop]

However, maybe we could report it as neutral state (not success nor failed), which what we are actually doing when the build.ignore setting is triggered. Not sure if we want to do it as "default", or we want to do it "only under certain condition" though. Thoughts @kitop ?

Mhm... this is a good question. We already have some related internal issues around it (https://github.com/netlify/bitballoon/issues/4112, https://github.com/netlify/bitballoon/issues/4572, https://github.com/netlify/bitballoon/issues/5307).

The cancel event is always user-triggered, either via UI or build plugins. I'd be OK with it always being neutral. It'll be consistent with build.ignore which is also user-triggered. Updating the comment to say "canceled" rather than "failed" will be a big improvement in terms of clarity as well.

[ehmicky]

This makes more sense to me as well.

[keiko713]

Cool, let's go with the neutral state then. Would be indeed nice to fix this with other related issues but we could also scope this down. I'll create an internal issue to track this 👍

[ehmicky]

This was reported in Netlify community as well: https://community.netlify.com/t/canceling-build-and-pull-request-in-github/16123/2

[andefred]

Do we have any status on this yet? Or a possible workaround when you are deploying multiple apps from an NX repo, based on the blogpost on your blog... Would be great if that did not report builds as failed to github. I think that either introduce a new flag to the cancelBuild command so that we could do something like utils.build.cancelBuild({ message: 'Intentionally canceled by plugin', gracefulExit: true}) and based on the new flag the github hook could then report as neutral instead. The default value could be false, so that if people are already using this function to intentionally fail builds, it won't break for them.

[ehmicky]

Hi @andefred,
Thanks for chiming in. This feature is in our backlog, and we are working on prioritizing it so we can ship it as soon as possible. Thanks for the additional feedback!

[cwcoffman]

I am having the same issue, and have to manually trigger EVERY build. Pretty please, fix this!

Just to confirm, this is my typical build logs, even after significant changes:

10:44:29 AM: Build ready to start
10:44:30 AM: build-image version: b0258b965567defc4a2d7e2f2dec2e00c8f73ad6
10:44:30 AM: build-image tag: v3.4.1
10:44:30 AM: buildbot version: 0a44c930054be748eff0c581d346282fece89cc0
10:44:31 AM: Fetching cached dependencies
10:44:31 AM: Starting to download cache of 135.4MB
10:44:33 AM: Finished downloading cache in 2.201351282s
10:44:33 AM: Starting to extract cache
10:44:36 AM: Finished extracting cache in 3.598670794s
10:44:36 AM: Finished fetching cache in 5.903589307s
10:44:36 AM: Starting to prepare the repo for build
10:44:37 AM: Preparing Git Reference refs/heads/master
10:44:39 AM: Different publish path detected, going to use the one specified in the Netlify configuration file: 'System Architecture/Blast API/public' versus 'public/' in the Netlify UI
10:44:39 AM: No changes detected in base directory. Returning early from build.
10:44:39 AM: Failed during stage 'checking build content for changes': Canceled build due to no content change
10:44:39 AM: Finished processing build request in 8.787778378s