I've looked at a few of the jobs in https://codeready-workspaces-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/pre-release/view/OCP%203.11/ I see they're all using unique namespaces but some are CHE_OPENSHIFT_PROJECT and some are DEFAULT_OPENSHIFT_PROJECT.

When I copied https://codeready-workspaces-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/pre-release/view/OCP%203.11/job/pre-release-upstream-che-e2e-tests-against-OCP-oc3/ as https://codeready-workspaces-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/pre-release/view/OCP%203.11/job/pre-release-upstream-che-e2e-tests-against-OCP-oc4/ I didn't realize that this variable is hardcoded and uniquely defined in each job, so I ended up with two jobs that if run in parallel, would collide (one would delete the resources of the other).

So, I propose we should fix two things:

a) standardize the boilerplate code so it uses OPENSHIFT_PROJECT, rather than CHE_OPENSHIFT_PROJECT or DEFAULT_OPENSHIFT_PROJECT

b) use `CHE_OPENSHIFT_PROJECT=${JOB_NAME//_/-}` (replacing all underscores w/ dashes, as underscores in namespace are not supported, but are allowed in Jenkins job names) in the startup/teardown code so that every job, if copied, will use a unique project namespace for deployments.

Of course this would best be achieved using JCasC & Jenkinsfiles so that chunks of Jenkins config are reusable across multiple jobs that do the same standup/teardown work before and after running specific verification tests.