chore(deployment): bump apiVersion from v1beta1 to v1 by gferreir · Pull Request #1392 · tektoncd/catalog

gferreir · 2026-09-17T14:12:13Z

Changes

Mechanical API version bump for the argocd + deployment/CD task family, as part of the
v1beta1 → v1 migration tracked in #1381.

Tasks updated

Task	Old → New	Changes
argocd-task-connect-repo	0.1 → 0.2	apiVersion v1, minVersion 0.50.0, removed hardcoded `namespace: argocd`
argocd-task-sync-and-wait	0.2 → 0.3	apiVersion v1, minVersion 0.50.0
blue-green-deploy	0.2 → 0.3	apiVersion v1, minVersion 0.50.0, tests/samples bumped
gke-deploy	0.1 → 0.2	apiVersion v1, minVersion 0.50.0
helm-upgrade-from-repo	0.3 → 0.4	apiVersion v1, minVersion 0.50.0, tests/samples bumped
helm-upgrade-from-source	0.4 → 0.5	apiVersion v1, minVersion 0.50.0, tests/samples bumped
istio-canary-release	0.1 → 0.2	apiVersion v1, minVersion 0.50.0, pinned `origin-cli:4.6` to digest, samples bumped
kamel-run	0.1 → 0.2	apiVersion v1, minVersion 0.50.0, tests/samples bumped
kn-apply	0.2 → 0.3	apiVersion v1, minVersion 0.50.0

Each task was created using copy-then-modify per CONTRIBUTING.md: one commit
copies the previous version directory, a second commit applies the version bump.
None of these tasks use PipelineResources or other v1beta1-only constructs.

argocd-task-connect-repo had metadata.namespace: argocd hardcoded. Catalog
tasks should not pin a namespace, so that field was dropped in 0.2.

istio-canary-release referenced quay.io/openshift/origin-cli:4.6 without a
digest. 0.2 pins it to @sha256:6722d5041b472ac61a294647f7fa02fb432a948835bb780cc73cd221a9291a2c.

Note: #1318 is still open and also creates helm-upgrade-from-repo/0.4 (without
an API bump). This PR starts from current 0.3. If #1318 merges first, this
will need a version rebase to 0.5.

Validation

yamllint passes for all modified files
No remaining tekton.dev/v1beta1 references in any of the new version directories

Note on pre-existing conditions

Several of these tasks interpolate $(params.*) directly in script: blocks,
and some keep mutable image defaults via params (e.g. kn-apply :latest).
Those are inherited from the previous versions and not introduced by this PR.
Script injection hardening will be addressed in follow-up PRs as part of #1381.

Ref: #1381

/kind cleanup

Submitter Checklist

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

Follows the authoring recommendations
Includes docs (if user facing)
Includes tests (for new tasks or changed functionality)
- See the end-to-end testing documentation for guidance and CI details.
Meets the Tekton contributor standards (including functionality, content, code)
Commit messages follow commit message best practices
Has a kind label. You can add one by adding a comment on this PR that
contains /kind <type>. Valid types are bug, cleanup, design, documentation,
feature, flake, misc, question, tep
Complies with Catalog Organization TEP, see example. Note An issue has been filed to automate this validation
- File path follows <kind>/<name>/<version>/name.yaml
- Has README.md at <kind>/<name>/<version>/README.md
- Has mandatory metadata.labels - app.kubernetes.io/version the same as the <version> of the resource
- Has mandatory metadata.annotations tekton.dev/pipelines.minVersion
- mandatory spec.description follows the convention
```
  ```
    spec:
      description: >-
        one line summary of the resource
  
        Paragraph(s) to describe the resource.
  ```
```

See the contribution guide for more details.

Signed-off-by: gferreir <guilherme.nmf@gmail.com>