Buildah image in few tasks was not pointing to latest
image release tag, so updated the image to point to
latest release.
Signed-off-by: Divyansh42 <diagrawa@redhat.com>
Earlier git-clone assumes `master` as default branch, but after #2835
`master` is no more default branch. Hence, updated the git clone task
fetch a remote repository's default branch instead of assuming "master"
when revision is "".
Signed-off-by: Divyansh42 <diagrawa@redhat.com>
The following task uses the released version of tekton operator to install tekton components on a new cluster. By default Tekton pipelines are installed but if we want to install other components as well then we can specify their version in the parameters of the task and respective component will get installed.
Signed-off-by: vinamra28 <vinjain@redhat.com>
The end to end test attaches a sidecar with a image registry for tasks to push into to. However, the function add_sidecar_registry sets the sidecar registry instead of appending it. Removing the function from test to remove this bug. There is a local registry being added to the test that is deployed with deployment and svc. The svc is referenced during the test instead of the sidecar. #481
This PR is to improve the existing maven tasks and support context directory switch in case of multi-module maven projects. Also the settings.xml was being `cat` so removed that also. This is being added as version 0.2 in maven task
Signed-off-by: vinamra28 <vinjain@redhat.com>
This commit adds git-clone v0.2. One default behaviour has changed
and one new param has been introduced in this version:
1) Tasks that don't start their script with #! automatically receive
a preamble that includes `set -x`. This results in verbose output
because every command is printed while the Task is running.
This commit adds a new param, "verbose", that - when set to "false"
- prevents the commands run by the task from being printed to logs.
The default value is "true": the commands run by the task will be
printed in the log.
2) The git-clone Task offers a param, deleteExisting, that cleans
any existing directory before performing a clone into it. This
has previously been set to "false" by default since it's potentially
destructive. But it sounds like there's quite often a request for
how to enable this behaviour, so it seems like the more pragmatic
default would be "true".
This commit sets deleteExisting to be defaulted to "true" so that
any existing git checkout is removed prior to a new clone being
performed.
If the user want to use another image than what we release on gcr.io let give
this option by introducing the param `gitInitImage` to set this up which would
default to the gcr.io image as it was before.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
Also, modify the git-batch-merge test to use actual changes - using
`kelseyhightower/nocode` was cute, but ended up masking the actual
problem that not setting `depth` to `0` by default was making all
merges fail. So let's use our own repo, two merged PRs, and the
ancestor of the first of those PRs.
fixes#477
Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Use variable $(workspaces.source.path) for path (pytest)
Add OWNERS file
Use latest tag for the python images as default
Signed-off-by: wumaxd <wurzer.maxi@gmx.de>
* Only intall the requirements when the file is here
(sometime we write pure python script that doesn't need external libs)
* fix installing pylint when needed
* Use variable $(workspaces.source.path) for path
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
I added support for TaskRunResults for this task. This change adds four results:
- the sha256 hash of the bdist package and the sdist package.
- the package name
- the package version
I also fixed a permission issue in the sample - I could not get this to run as a non-root
user (even without my change). The git repo is cloned correctly, but the default user of the
twine image does not have write permissions in this directory.
The following task uses `coverage` dependency in python to measure code coverage of Python projects. This task works along with the pytest so that coverage can be calculated properly.
Signed-off-by: vinamra28 <vinjain@redhat.com>
The existing kubectl-deploy-pod task contained all the sample TaskRuns along with the task definition so with this PR I am moving them to their respective directories and also fixed some of the links in the README.
Signed-off-by: vinamra28 <vinjain@redhat.com>
Blue-Green deployment is one of the deployment strategy being used to deploy the newer version of the application on kubernetes keeping the previous version in production so that if
newer version fails then the router can be switched back to the previous version of the deployment without any downtime.
Signed-off-by: vinamra28 <vinjain@redhat.com>
This commit represents a complete update of the OpenWhisk to Knative pipeline from v1alpha1 level to v1beta1 resource levels. This pipeline also adds conditional logic to support additional "branches" of the pipeline to sequence tasks that can detect and build serverless applications for not only NodeJS (previously the only lang. supported), but also Python and Java. In addition, this pipeline utilizes a workspace for sharing data/state across tasks. Each language branch has its own sample functions with instructions for users to build and test on knative the services they build.
The following task can be used to trigger an existing Jenkins pipeline from Tekton using the CURL request by providing the required parameters.
Signed-off-by: vinamra28 <vinjain@redhat.com>
Centralize all the the git-clone apply commands we had around the
pre-apply-task-hook to a central common function.
This will make easier to have the same git-clone task version used everywhere.
Add some documentation about the helper functions along the way.
Signed-off-by: Chmouel Boudjnah <chmouel@redhat.com>
This will the fix the pytest and pylint task
which fails if run as non root user
in case of non-root user, it install at
location which is not in PATH of image
so adding the required PATH fix the issue
Boskos is a tool that allows one to create a pool of cloud projects
(definitely GCP, I think it supports other providers as well), and
manages acquiring, releasing, and cleaning them between leases.
We use it for Tekton test infrastructure for our end to end tests and
we'd like to use it for our catalog Tasks as well.
This commit adds boskos acquire and release Tasks.
The acquire Task also creates a pod in the running cluster to perform
heartbeating so that boskos knows that the resource is still in use.
The intention of the release Task is that it would be run in a
Pipeline's `finally` clause, however today that would be difficult
because finally Tasks can't yet use the results of other Tasks, but this
functionality is on the way: https://github.com/tektoncd/pipeline/issues/2557
This is part of the work in #373 to create a Pipeline for the catalog.
The following task can be used to run the shell command (single/multiple) on remote Host by SSHing into the remote machine by providing the required credentials required to
login into that Host and get back the result as output.
Signed-off-by: vinamra28 <vinjain@redhat.com>
As a user there are some instances where I need to use docker because there is a makefile/script that uses docker in a very niche way. A Tekton Task was added with a docker sidecar.
As part of #373 I'm continuing to create Tasks that we can use to run
tests for items in the catalog. This Task creates a cluster within a GKE
project and is based on the way we create clusters for the existing end
to end tests we have in Tekton, which are themselves based on Knative,
when are THEMselves based on k8s. These tests all use a tool called
kubetest, which is responsible for invoking boskos (see #408) and
creating a GKE cluster
(https://github.com/kubernetes/test-infra/tree/master/kubetest).
This Task attempts to create a cluster in the same way, which based on the
output in the end to end logs seems to consist of creating the cluster
and setting up a firewall for it.
I'm not sure if this belongs in the catalog itself since it is specific
to our own end to end tests and isn't as generic as other catalog tests,
so if we want to move this into the test directory that seems fine, but
I also think it could be an okay addition to the catalog on its own (esp
if other k8s based projects that test against GKE want to use it.)
