WIP: Move LimitRange Examples Out of no-ci Folder

[danielhelfand]

Closes #2071

When these examples were originally introduced, they needed to be located under the no-ci folder since the examples created a LimitRange that caused other examples to fail. At the time, the implementation for using LimitRanges required users to specify a LimitRangeName on the PipelineRunSpec or TaskRunSpec. No other examples did this, which caused failures during integration tests. All these examples should now be able to succeed even with a LimitRange in place since no LimitRangeName is needed to be specified (#2020).

I think what makes sense is to namespace these examples as discussed in this issue in plumbing and keep other examples all running in a particular namespace. Not sure if this would require anything different to detect for failures of these examples since they are in different namepaces than other examples, but my thought would be to have these serve as a form of e2e testing for LimitRanges.

Submitter Checklist

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

N/A

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign imjasonh
You can assign the PR to them by writing /assign @imjasonh in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[danielhelfand]

/test pull-tekton-pipeline-integration-tests

[vdemeester]

@danielhelfand I wonder if it make sense to move them from no-ci, as with this, we only validate the yaml, we are not doing any check on if it ran successfully or not

[vdemeester]

Our "check" won't check this though, as "did it run sucessfully", as, it only look into the current namespace (default or one created by the CI 🤔).

[danielhelfand]

By chance, do you know if other namespaces could be added to check?

[vdemeester]

By chance, do you know if other namespaces could be added to check?

Yep they could 👼

[danielhelfand]

Let me look into e2e-common.sh and see what I can do to try and add the results.

[danielhelfand]

Closing this in favor of adding something to go e2e tests