CLOUD-869 Inverting the check to test whether the previous build's result is anything other than SUCCESS

[ptankov]

CHANGE DESCRIPTION

Problem:
The previous build can be NOT_BUILT for which I do not check.

Solution:
Inverting the check to test whether the previous build's result is anything other than SUCCESS is a cleaner approach. This way, we don’t need to explicitly list all the non-success states (FAILURE, ABORTED, UNSTABLE, NOT_BUILT), and the code remains robust against any additional statuses Jenkins might introduce in the future.

CHECKLIST

Jira

• Is the Jira ticket created and referenced properly?
• Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
• Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

• Is an E2E test/test case added for the new feature/change?
• Are unit tests added where appropriate?

Config/Logging/Testability

• Are all needed new/changed options added to default YAML files?
• Are all needed new/changed options added to the Helm Chart?
• Did we add proper logging messages for operator actions?
• Did we ensure compatibility with the previous version or cluster upgrade process?
• Does the change support oldest and newest supported PG version?
• Does the change support oldest and newest supported Kubernetes version?

[JNKPercona]

Test name	Status
custom-extensions	passed
custom-tls	passed
demand-backup	passed
finalizers	passed
init-deploy	passed
monitoring	passed
one-pod	passed
operator-self-healing	passed
pitr	passed
scaling	passed
scheduled-backup	passed
self-healing	passed
sidecars	passed
start-from-backup	passed
tablespaces	passed
telemetry-transfer	passed
upgrade-consistency	passed
upgrade-minor	passed
users	passed
We run 19 out of 19

commit: 8080b38
image: perconalab/percona-postgresql-operator:PR-1022-8080b383d