Annotation about linux/amd64, linux/s390x, and linux/ppc64le platforms was
added to the latest versions of the golang-* tasks.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
The image is used in many catalog tests. To run the tests on many
platforms, the image should be the multi-arch one (at this moment -
linux/amd64, linux/ppc64le, linux/s390x, linux/arm64).
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Helping a user in Knative slack, I noticed that the documented default on TektonHub (and the catalog) was different from what was actually in the task. This corrects the README.
When adding `fixtures` volume, we need to consider whether the task
already has a volumes section. If the volumes is already defined, then
we should add `fixtures` rather than replacing the whole volumes.
quay.io/buildah/stable:v1.18.0 and quay.io/skopeo/stable:v1.3.0 are
multi-arch images, bumping them for buildah and skopeo-copy tasks will
allow to run the tasks on different architectures.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Annotation about linux/amd64, linux/s390x, and linux/ppc64le platforms
is added to the latest versions of the send-to-* tasks.
Curl image used in the tasks is upgraded from 7.68.0 to 7.70.0 to use
multi-arch version.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Annotation about linux/amd64,linux/s390x,linux/ppc64le platforms was
added to the latest versions of the kaniko task, as well as information
which custom images to use for linux/s390x and linux/ppc64le platforms.
JQ_IMAGE parameter is introduced with default value from the existing
tas to be able to use custom image for non-Intel architecture.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Annotation about linux/amd64, linux/s390x, and linux/ppc64le platforms
was added to the latest versions of the github-* tasks.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Fix shell script
Remove newline
Remove resources
Fix whitespace
Get rid of newline
Add first lines again
Reformat
Add dashes
Update newlines
Small review comments
Add test
Fix workspace
Cleanup test
Fix for location of tools
Fix typo
Fix comment
Fixes for review comments
Adjust README as well
Using github.com/cli/cli it takes a PR URL as first argument and check
it out.
It will then detect automatically the old and new version and post a
comment to the PR with the diff and copy it in your clipboard (with
xclip on Linux and pbcopy on OSX)
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
When discussing some potential ways a Task could be compromised,
@afrittoli mentioned that if a Task refers to some remote source for a
script, there is the potential for that source to be modified and run
something malicious inside a Task. As he described this, he mentioned
that our catalog recommends putting scripts into configmaps, which I was
surprised to see. A script inside a configmap does have this potential
attack vector (though you'd have to have write access to the configmap
to pull it off) but I'm actually a bit more concerned that this isn't
a great solution for maintaining scripts over time. Not to mention that
I'm not how we would support this in the catalog (we'd have to start
supporting applying and versioning ConfigMaps alongside the Tasks that
reference them).
So this commit changes the recommendation to recommend 'graduating'
large scripts from script to tools and treating them like you'd treat
other code. This is still not a fantastic solution as it requires you to
maintain and publish your own images but I think it's a step in the
right direction (and if it helps, I could also see a world where we
support storing and publishing those images via the catalog as well -
though I'm pretty sure @vdemeester disagrees with me here).
Annotation about `linux/amd64`,`linux/s390x`,`linux/ppc64le` platforms
was added to all versions of the tkn, git-cli, pull-request
and kubeconfig-creator tasks.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
- Initially all tags were mapped to categories in Hub,
for e.g. config.yaml: https://github.com/tektoncd/hub/blob/master/config.yaml,
so whenever a new tag was added in a task it was mapped to a category called `others`.
Hence before every release we had to manually map these new tags to some category,
hence after the discussion in Catalog and Hub WG, a proposal was created for adding
a category as an annotation.
- PR to update the TEP-0003-Tekton Catalog Organization: https://github.com/tektoncd/community/pull/352
Signed-off-by: Puneet Punamiya <ppunamiy@redhat.com>
helm-upgrade-from-source tasks
As well as update helm image to use multi-arch version of it.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Allow configure the image name and default to latest,
The latest goreleaser version probably break the old version so bumping
the task version here and allow to override if the user wants it with
params.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
This task is a Golang Tekton Task to fuzz Go projects
It uses the native Go Fuzzing Beta for dynamic analysis to find issues
in your code.
The release announcement https://blog.golang.org/fuzz-beta notes that:
"Fuzzing is a type of automated testing which continuously manipulates
inputs to a program to find issues such as panics or bugs. These
semi-random data mutations can discover new code coverage that existing
unit tests may miss, and uncover edge case bugs which would otherwise
go unnoticed. Since fuzzing can reach these edge cases, fuzz testing is
particularly valuable for finding security exploits and vulnerabilities"
The task requires min pipelines version 0.17.0 as it uses two optional
workspaces. First workspace is for passing the manifests which we want
to apply on the cluster and second workspace can be used to mount the
kubeconfig file if in case we want to run the oc command on another
cluster.
Signed-off-by: vinamra28 <vinjain@redhat.com>
The README was showing that the task uses the input resource of
cluster-type but the resource being used was of git-type so fixing that.
Signed-off-by: vinamra28 <vinjain@redhat.com>
These changes introduce the Buildpacks Pipeline. This pipeline
builds source into a container image using Cloud Native Buildpacks.
To do that, it uses builders to run buildpacks against your application source.
It relies on git-clone, buildpacks, and buildpacks-phases tasks to perform
it's tasks.
Signed-off-by: Javier Romero <rjavier@vmware.com>
Following TEP 70, tekton.dev/platforms annotation can be used to
specify on which platforms the resource can be run.
- add best practices for platform information in the recommendations.md
- add example of usage for tekton.dev/platforms annotation
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Add a parameter through which we can set the `HOME` env variable which
if not provided will default to `/tekton/home`. Also set the default
`workingDir` as `/workspace`.
Signed-off-by: vinamra28 <vinjain@redhat.com>
git-clone 0.1:
Add a parameter through which we can set the `HOME` env variable which
if not provided will default to `/tekton/home`
git-clone 0.4:
Changed the default value of userHome param from `/root` to
`/tekton/home` as it was not matching the README.
Signed-off-by: vinamra28 <vinjain@redhat.com>
