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>
This script will allow the developer to test a task directly withouth having to
send it to the CI and wait that all tasks runs to test it.
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>
To make sure the checklist is useful and folks don't ignore it, I think
it's important to keep only the items we need to in there.
If we can enforce something with CI, I suggest we do not include it in
the checklist - if we want to write down guidance somewhere else I think
that totally makes sense, but not in the checklist.
From https://github.com/tektoncd/catalog/issues/387 it looks like
linting should be applied automatically to each PR so I don't think we
need to include this checklist item.
This will refactor the namespace name to have version of task
in namespace name as current logic may create issue in case
of multiple versions running in same namespace as pid will
remain same
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.)
- Override /tekton/home for the detect and build phases of the lifecycle to hide registry credentials from buildpack code.
- Run analyze, restore, and export in the lifecycle image published by buildpacksio to hide registry credentials from untrusted builders.
Signed-off-by: Natalie Arellano <narellano@vmware.com>
- Set HOME env to /workspace
- Use $HOME for "home" wherever possible
- Gradle: mount empty dir at ~/.gradle to make it globally writable
- Maven: script to `script:` to use "$HOME" variable
Additionally, remove commented out references to ADDITIONAL_TAGS; that will be added as a separate issue.
Signed-off-by: David Freilich <dfreilich@vmware.com>
With the release of Platform API 0.3 (implemented in github.com/buildpacks/lifecycle v0.7.0), there is a creator binary that simplifies the CNB experience; calling it runs all of the individual lifecycle phases, and minimizes the number of separate containers needed for the process. As such, we moved the buildpacks task to use it.
At the same time, it is also helpful, in some scenarios, to run the individual phases; it allows for greater control of secrets, amongst other things. As such, we moved the original task to buildpacks-separate-phases to allow users the choice.
This commit also updates the READMEs, making them a bit clearer about what CNBs are and what the tasks do, as well as adding in the Paketo builders to the example builders.
Signed-off-by: David Freilich <dfreilich@vmware.com>
The suffix v3 was a piece of buildpacks history, stemming from the initial start of the buildpacks concept, but isn't relevant to current consumers of the buildpacks task. To simplify it, and to fit with other task styles, we are removing v3
Additionally, we are updating the list of suggested builders, to reflect the current status of pack builders. NOTE: Paketo builders currently have a bug and don't work in Tekton, and until that issue is resolved, we aren't adding them in the list.
Signed-off-by: David Freilich <dfreilich@vmware.com>
