Use legacy build and test golang tasks

[afrittoli]

Changes

Use golang-build-legacy and golang-test-legacy.
Theres are identical copies of the existing ones, designed to allow
pipeline, dashboard and triggers to switch to them.

This step uncouples the various projects so that we way then:

• switch pipeline, dashboard and triggers one at the time to a publish
  task and release pipeline that use workspaces, no resources and thus
  the catalog version of golang-build and golang-test
• once the three projects are migrated, the legacy tasks will be
  removed

See tektoncd/plumbing#734

Signed-off-by: Andrea Frittoli andrea.frittoli@uk.ibm.com

/kind misc

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

• If you are adding a new binary/image to the cmd dir, please update
  the release Task to build and release this image.

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

NONE

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbwsg]

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

[pritidesai]

this is interesting, thanks @afrittoli
/lgtm

You don't have to answer this, but, why migration and how are we handling this migration process?

[afrittoli]

this is interesting, thanks @afrittoli
/lgtm

You don't have to answer this, but, why migration and how are we handling this migration process?

The current release process uses pipeline resources, and a version of golang tasks hosted in the plumbing repo. We should dog food our latest and greatest features like workspaces and results instead, and use tasks from the catalog where possible. The tasks from the catalog also only work with workspaces.

[pritidesai]

That's great, didn't realize we are not using tasks from catalog on the dog fooding cluster. I recall now creating git resources while creating a release 🤪. Thanks! 👍