- 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>
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>
Add a parameter through which we can set the `HOME` env variable which
if not provided will default to `/tekton/home`
Signed-off-by: vinamra28 <vinjain@redhat.com>
Add a parameter through which we can set the `HOME` env variable which
if not provided will default to `/tekton/home`
Signed-off-by: vinamra28 <vinjain@redhat.com>
logining in from one container and having sync and wait run in a
separate containers does not work. Authenticate once and reuse the connection
across the containers in a pod is not supported. Sync and wait fails with
authentication error. Either we login at each step or collapse
sync and wait along with the login step. Or we could authenticate once and
find a way to how to reuse the same connection across the containers.
For now, combining everything into a single step.
Fix trailing space
Fix version obviously
Fix text typo
Add Test for Github Open PR
Fix hosts
Update test fixture
Add better and more tests
Use localhost
Fix HTTP and HTTPS
Fix typo
Add PR number and URL results
Fix tests and use correct URL
Remove duplicate line
Set correct URL over here as well
This will add a new version 0.4 in jib-maven task which
have only one change of different mounth rather than /etc/ssl/certs
as mounting at that location is overidding the default certs of
the image. This will make the certs to mount at different path
/tekton-custom-certs
This commit introduces a 0.4 version of git-clone, fixing several
problems with the 0.3 git-clone Task:
1. Credentials in 0.3 could not be passed directly to the Task via
a Workspace.
2. There was no support for running as a non-root user.
This commit introduces a new version of git-clone that fixes both
of these issues. Credentials (either basic-auth or ssh-directory)
can now be supplied directly using a Secret workspace. A nonroot
user is provided with UID 65532 that can clone repos without
requiring root permissions.
This use python multi string when getting the comment
params so we don't bug out on multi lines comments.
Signed-off-by: vinamra28 <vinjain@redhat.com>
Allow overriding the GO cache, GO mod caching and golangci-lint caching.
Optimize golang-build and golang-test to not do a fulll copy of the source
inside the GOPATH if we have a go.mod in source root directory.
Bumped task since we add a bunch into it.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
Update title with copy paste err
Add quotes to get rid of lint issues
Fix some more issues with shell linting
Linting - Add double quotes over here as well
Setup the incoming webhook as a secret due to it's sensitivity
* Allow defining the github api url
* Handle Exception better by showing the error message.
(i.e: in case if ntp is not syncronized the jwt token would not be issued)
Few task's README contains some url links which had
invalid directory path and was pointing to a invalid page
Signed-off-by: Shiv Verma <shverma@redhat.com>
In write-file task's tests we are checking whether file permission is
equal to `--w--wxr-T`. These permissions may vary depending on rbac
enforced cluster. Example on some cluster we can get the value as
`-rw-rwxr-T` thus failing the test.
In this commit I am removing the `grep -- '--w--wxr-T'` so that the
tests doesn't fail on other clusters.
Signed-off-by: vinamra28 <vinjain@redhat.com>
When the optional dockerconfig workspace is set, set the
DOCKER_CONFIG env variable accordingly.
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
The syntax of the find command was not correct, and the error was not
caught by CI because of the missing "set -o pipefail".
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
Add a new task that uses tkn bundle to publish a Tekton catalog as
bundles to a container registry. Each task corresponds to a dedicated
bundle, which task versions available as tags.
Optionally, bundles are tagged with an extra tag provided as an input
parameter.
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
Add a catalog task to write a parameter out as a file, creating
intermediate directories and setting permissions as necessary. While it
is possible today to have a workspace that is a mounted config map
variable, that provides limited support for expanding parameters into
the file (i.e. the [replace-tokens](https://hub.tekton.dev/tekton/task/replace-tokens) task).
Ultimately, my argument for adopting this task into the catalog is that
I believe others will also look for a file-writing task and their
experience of Tekton will be better if they find one.
Previously we passed params directly into the `script` block of
the clone step. Because Pipelines doesn't escape variable values
when interpolating them the behaviour of the task could be changed
by the contents of a param.
This commit changes the way params are provided to the script;
instead of being interpolated directly they are converted first
into environment variables and accessed through shell's `${}`
construct.
Added a new params to allow getting the application_id from the secrets
workspace, still allowing as params directly if user would like to use
this instead.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
This adds support for running kind within Tekton. This primarily configures
the Docker-in-Docker environment necessary to bring up kind clusters.
Users should invoke kind in their own runtime image to create / modify
clusters. See https://github.com/tektoncd/plumbing/pull/821 for an
example runtime image.
This change simply adds comments to secrets and other password/key
material that are used in testing. The usage of these secrets is okay
(they're all either dummy tokens or auth material set for local
instances spun up during tests), but adding comments to provide some
background for anyone browsing the code.
Also redacted a cert used in the buildah sample. While this was
safe since it was generated specifically for the sample, there isn't a strict
need for a valid cert here, so we can replace this with something that looks
cert-like instead.
Add an optional workspace to the kaniko task that can be used to
pass container registry credentials to the kaniko task.
This mechanism replaces the service account based one. The change
is not backward compatible, however it is not easily possible to
support both auth mechanism, since the service account one
requires setting DOCKER_CONFIG, which breaks the workspace based
one. Workspace are preferrable since they are available in all
deployments, while Tekton's built-in auth is only available when
it's enabled. While enabled is the default setting for now, it may
change in future, and it may already be disabled in various
deployments, where the kaniko task is today effecively unusable.
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
This task allows to update a status of GitHub deployment from a
Tekton pipeline. This task can be used while deploying or
after deployed (with `finally`) to show status at
GitHub deployment status tab.
Signed-off-by: Sunghoon Kang <hoon@linecorp.com>
- Add API_PATH_PREFIX to github-create-deployment task parameter
GitHub enterprise exposes API using path (e.g. `/api/v3`)
instead of host. `github-create-deployment/0.1` will fail on this case,
since `HTTPSConnection` does not allow path included host.
Co-authored-by: Vinamra Jain <vinjain@redhat.com>
Signed-off-by: Sunghoon Kang <hoon@linecorp.com>
Extend to test logic to be able to load the fixture reponse from a
file, so that we don't have to inline a long JSON doc into the fixture
config YAML. This is achieved by creating a config map with all the
files in the fixtures folder, and mounting that configmap as a volume
to the sidecar.
This allows improving the test for the github-add-comment task v0.4
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
Enhance the GitHub add comment task with the ability to update
a comment if applicable. This achieved by tagging comments with
and invisible (HTML comment) unique text, and looking for that
text to identify a comment.
This does not use the nodeid because that is generated by GitHub
and it would require task users to store known node IDs somewhere
across task executions.
Signed-off-by: Andrea Frittoli <andrea.frittoli@gmail.com>
Non-ascii characters would cause the task to fail to send the email because by default smtplib tries to encode the message in ascii. Adding the encode('utf-8') to the email body fixes the issue
- Add `APP_IMAGE_DIGEST` result
- Upgrade to Platform API 0.4
- Add support for build-time environment variables
- Replace use of PipelineResources with Params
Signed-off-by: Javier Romero <rjavier@vmware.com>
- Add `APP_IMAGE_DIGEST` result
- Upgrade to Platform API 0.4
- Add parameter to configure the `LIFECYCLE_IMAGE`
- Add support for build-time environment variables
- Replace use of PipelineResources with Params
Signed-off-by: Javier Romero <rjavier@vmware.com>
Updated refspec defaults because of upstream branch changes from `master` to `main` (`refs/heads/master:refs/heads/master`->`refs/heads/main:refs/heads/main`)
- Add parameter for the Terraform image
- Add proxy parameter
- Use official Hashicorp Terraform by default
- Better Terraform Environment Variable description
As of now github-add-comment task supports input of comments only via
params.
This PR adds support of workspaces if in case somebody wants to provide
the comments via some file. One such use case can be:-
In Catlin CI, logs are produced after executing catlin command on
changed files which can contain multiple warnings and these warnings can
be ingored by the user if not posted on the github PR as the CI is
green. So all the logs would be stored in a file with proper formatting
and then the shared workspace can be passed to the github-add-comment
task along with the filename containing the formatted logs.
Signed-off-by: vinamra28 <vinjain@redhat.com>
This patch includes-
Currently we have a file called `build-push-gke-deploy`
which has multiple resources in one file, this patch moves
the pipeline to the pipeline directory and it's corresponding
task to the support directory
Signed-off-by: Puneet Punamiya <ppunamiy@redhat.com>
The tasks orka-init and orka-teardown fails to create resources on the
cluster where rbac rules are enforced so running that as privileged
works fine.
Signed-off-by: vinamra28 <vinjain@redhat.com>
At the time of writing, the stable `docker:dind` is broken, the solution is to roll back to the previous version (https://github.com/containerd/containerd/issues/4837).
In other words, `docker:dind` should be temporarily replaced with `docker:19-dind`.
I think allowing users to specify the docker-in-docker image via params is the best way to get around this issue.
This PR corrects a potential race condition for the orka-deploy
and orka-teardown tests which causes the nightly integration test run to
fail. A runAfter condition is added to each test pipeline to avoid a
race condition where the pods created by the orka-deploy and
orka-teardown tasks are unable to be created when the orka-init task
has not yet created the secret and config map needed for pod config.
knctl has been sunset since 2 years and only supports Knative up to 0.2 (current version: 0.20).
The successor is kn for which there are also entries in the catalog.
Currently in pre-apply-task-hook.sh we are using `jenkins:lts` image
which gets updated on a regular basis which might break the CI while
testing the following tasks:- jenkins, trigger-jenkins-job.
Adding a tag+digest to the image used in test so that the tests don't
break in future.
Signed-off-by: vinamra28 <vinjain@redhat.com>
Credentials can be passed to the aws-cli via instance roles (with e.g. kiam).
So an installation of this task could look like this:
```
kind: Kustomization
resources:
- https://raw.githubusercontent.com/tektoncd/catalog/master/task/aws-cli/0.2/aws-cli.yaml
patchesStrategicMerge:
- |-
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: aws-cli
annotations:
iam.amazonaws.com/role: tekton-upload
```
Optional workspaces is supported since pipelines 0.17.0
minVersion in v0.1 of this task is 0.12.1, so a new v0.2 was created
which requires the newer pipelines version.
- Add parameter for the maven image
- Replace usage of PipelineResource to image name as param and image digest as
results
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
This introduces a Task for creating GitHub deployments for a given
repository. This allows people who rely on GitHub deployment events
for their CD systems to be able create them from within a Tekton
pipeline.
This task is pretty much just a wrapper around the GitHub API for
creating deployments. The main params required are the ref
and environment for the deployment, and we fall back to the API's
defaults for the other params.
Latest image versions have multi-arch support, it will allow to use the same
catalog tasks for many hardware architectures.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Since buildah has been built with the latest golang 1.15 version which has SAN
enforcement, we provide subjectAltName in the generation of self generated
certificate.
See https://security.stackexchange.com/a/183973
Image sha specified in git-cli and git-rebase tasks is for
amd64 version of alpine/git:v2.26.2 image. The image is actually
multi-arch one.
Replacement of image sha to point to multi-arch version will allow to
use the same catalog task for many hardware acrhitectures.
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
multi-arch tkn image allows to use the same catalog task in the setup
for many hardware acrhitectures (latest tkn image is available for
linux/amd64, linux/s390x and linux/ppc64le)
Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>
Upstream catalog nightly is failing with the error
`error: error parsing STDIN: error converting YAML to JSON: yaml: line
2: mapping values are not allowed in this context` which is occuring
while creating the SA in `pre-apply-task-hook.sh` as the SA YAML was
first created and then applied and during this process the error is
occuring.
The PR fixes that by directly creating the SA and not first generating
the YAML and then applying in next step.
Signed-off-by: vinamra28 <vinjain@redhat.com>
This change adds a set of modular Tasks to integrate Tekton with Orka
by MacStadium. Orka allows users to run macOS builds and workloads on
real Apple hardware. An Orka / Tekton integration will allow the
utilization of macOS build agents for CI jobs that run on Tekton
pipelines.
The tasks orka-init, orka-deploy and orka-teardown are designed to work
together in order to allow the utilization of multiple macOS
build agents in a CI/CD pipeline. The orka-deploy Task allows the user
to provide a build script as a parameter, and will allow the user to
store build artifacts in a Tekton workspace. The orka-init and
orka-teardown tasks create and delete virtual machine configurations.
This is accomplished by making calls to the Orka API running in a
separate Kubernetes cluster over a VPN connection.
Earlier version of s2i uses PipelineResources which are now deprecated.
Also the s2i task is missing the digest in results.
With this PR:-
- Removing the usage of PipelineResources and using equivalent task from
catalog in the tests.
- Storing the digest in results so that it can be used later on by
another task.
- Adds optional workspace for the cert dir to pass to buildah --cert-dir flag.
Signed-off-by: vinamra28 <vinjain@redhat.com>
To run Orka in OpenShift successfully we need to run the build step as privileged else some operations are not permitted without privilege access
Signed-off-by: vinamra28 <vinjain@redhat.com>
In quay.io if a tag is repushed, the previous digest becomes in-accessible.
So removing the digest from skopeo-copy task as the current digest was in-accessible.
Signed-off-by: vinamra28 <vinjain@redhat.com>
- git-cli examples moved from git-cli/examples/git-cli -> git-cli/examples/
- git-rebase examples moved from git-rebase/examples/git-rebase -> git-rebase/examples/
- changed workingdir -> workingDir in git-rebase
- corrected install command in az
- improved YAML in readme for proper rendering
Signed-off-by: vinamra28 <vinjain@redhat.com>
There were multiple examples which were not a part of that particular task were not removed at the time of catalog reorg
Signed-off-by: vinamra28 <vinjain@redhat.com>
* Making it easier to overwrite multiple values,
instead of defining them all in overwrite_values.
* Changing param helm_version to helm_image and let
the user define the entire container repo+image.
This change adds a Task to integrate Tekton with Orka by MacStadium.
Orka allows users to run macOS builds and workloads on real
Apple hardware. An Orka / Tekton integration will allow the utilization
of macOS build agents for CI jobs that run on Tekton pipelines.
The orka-full Task will allow the utilization of a single macOS
build agent, allowing the user to provide a build script as a
parameter, and will allow the user to store build artifacts in a
Tekton workspace. This is accomplished by making calls to the Orka
API running in a separate Kubernetes cluster over a VPN connection.
Tekton Pipeline 0.18.0 was just released and as part of the release
process, bumping up the following images in the catalog tasks:
git-batch-merge - v0.17.3
git-clone - v0.17.3
0.18 contains bug fix for git-init and therefore bumping related tasks only.
Adding tests for blue green deployment task. The test will first
deploy version v1 of an application and service pointing to version
that deployment using `pre-apply-task-hook.sh` script and using taskrun will
deploy version v2 of that application and patch the service to point to v2 version
of the application
Also modifying the images in deployment manifests present in samples as the previous image
is not accessible now
Signed-off-by: vinamra28 <vinjain@redhat.com>
Args wasnt expanded properly, it showed like this when running the task:
`[pthon-lint : pylint] /tekton/scripts/script-0-s2wjl: line 8: inputs.params.args: not found`
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
We are bumping the buildah task to 0.2 since this needs at least pipeline
0.17.0.
This will add a optional workspace for the cert dir to pass to buildah
--cert-dir flag.
I have modified the test to create a registry with SSL certs and make the
buildah task using it.
This add a complete example on how to use this with the openshift internal
registry.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
the install of requirements.txt was removed from the 0.1 task but it is actually
needed for pylint, since it would error out if it can't find the dependences.
We make sure we can install them as user since the image assume root and that
would not work on some k8 install (ie: openshfit and others).
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
We had previouslly the triggers-jenkins-job task, this task is more generic and
allows more operations, it currently support starting a jenkins job and getting
the log of a build. It allows as well to wait that the job had started or that
the job has finished.
With this more generic task it makes it easier to have other jenkins operations
in there.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
- Previously catalog's task has some images that are not
tagged properly,this patch fixes these images by adding
the digest
- Soon once Catlin is added to the CI it will throw error
for those images which don't have proper tags
co-authored by:- @PuneetPunamiya
Signed-off-by: vinamra28 <vinjain@redhat.com>
The tkn task will be able to work with a kubeconfig for a cluster so that it can operate on it. The following task can also accept a SCRIPT as input so that we can run multiple tkn commands.
Signed-off-by: vinamra28 <vinjain@redhat.com>
The golang-test and build tasks attempt to use variable interpolation in a workspaces.mountPath
field where it isn't supported. This results in the source code being mounted in a directory
called, literally, "$(params.package)".
This commit updates the golang-test and build tasks to mkdir the package directory and copy
the source code into it, then cd into it and run `go test`/`build`. This should result
in better expected outcome - the source will be in the package directory that it expects
to be.
- Bump a new pylint task to 0.2
- Use an image which already has pylint and not auto install it every time we
run the task.
- Convert the spec to pipelineSpec
- Do not try to install requirements.txt modules since pylint doesn't need it.
- Remove the ability to choose another python version since you probaby would
not need it for a static analyzer. If you really need it you can redefine the
image params targetting a custom container image.
Co-authored-by: Maximilian Wurzer <62810491+wumaxd@users.noreply.github.com>
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
We were previously using the outdated git_clone version 0.1 in the
add_git_clone_task function.
So let's introduce a more generic function :
```
add_task ${task} ${version}
```
if version is 'latest' it will always install the latest version of the task.
Change all pre-apply-task-hook to use that function instead.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
The following task contains `mypy` linter which is a popular static code analyser for python that checks code as described http://mypy-lang.org/
Signed-off-by: vinamra28 <vinjain@redhat.com>
Rewrite the triggers-jenkins-job, the arguments and params are about to same.
Starting from Jenkins LTS 2.176.2 we need to create a crumb and capture the
cookie jar to make the subsequent requests.
https://support.cloudbees.com/hc/en-us/articles/219257077-CSRF-Protection-Explained
Add tests :
We spins up a deployment with a jenkins lts and expose a service to it so our
task can access it.
We do some ninja execing into the pods to create a jenkins job in there and
setup the configmap secret.
We probably should drop the CRUMB setting since it will not work anymore but it
is harmless since we are regenerating it anyway.
Todo: need to test with jenkins image that is older than 2.176.2, but it
probably should work
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
