Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions task/create-gitlab-release/0.2/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Create Gitlab Release

It is typical to create a Gitlab tag at the moment of release to introduce a checkpoint in your source code history,
but in most cases users will need compiled objects or other assets output, not just the raw source code.

Gitlab Releases are a way to track deliverables in your project. Consider them a snapshot in time of the source,
build output, artifacts, and other metadata associated with a released version of your code.

This `task` can be used to make the `gitlab release`.

Task can also be used to upload `assets` including `binaries` of the released version, with the release.

## Install the Task

```
kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/create-gitlab-release/0.2/create-gitlab-release.yaml
```

## Parameters

- **TAG_NAME**: A git tag name that will be created with this release(_e.g:_`v1.0.0`).
- **NAME**: The Name of the release (_e.g:_`First release`).
- **DESCRIPTION**: A short description of the release (_default:_`""`).
- **RELEASE_REF**: It can be a commit SHA, another tag name, or a branch name (_default:_`master`).
- **PROJECT_ID**: The Gitlab id of the project, can be found on the repository page of the gitlab (_e.g:_`18587362`)
- **UPLOAD_ASSET_NAME**: The name of the asset that needs to be uploaded (_default:_`""`).
- **UPLOAD_ASSET_URL**: The uplaod URL for the hosted asset (_default:_`""`).
- **GITLAB_TOKEN_SECRET**: The name of the `secret` holding the gitlab-token (_default:_`gitlab-token`).
- **GITLAB_TOKEN_SECRET_KEY**: The name of the `secret key` holding the gitlab-token (_default:_`GITLAB_TOKEN`).


## Secrets
* `Secret` to provide personal `access token` of the Gitlab.

Check [this](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) to get personal access token for `Gitlab`.

## Platforms

The Task can be run on `linux/amd64` platform.

## Usage

This task expects a secret named gitlab-token to exists, with a Gitlab personal access token in `GITLAB_TOKEN` with enough privileges to create a release.

At present, `Gitlab` doesn't provide the functionality to upload any file to the release directly, however file that is hosted on any platform (i.e `aws s3` or `gitlab`) can be uploaded with the release by providing the hosted file `URL path` as the param to the task.

To make a release put all the required params in the Taskrun, add required secrets and release will be done.

`Secrets` can be created as follows:
```
apiVersion: v1
kind: Secret
metadata:
name: gitlab-token
type: Opaque
stringData:
GITLAB_TOKEN: $(personal-gitlab-token)
```

This [samples](../0.1/samples/run.yaml) can be referred to create Taskrun for Gitlab release.
92 changes: 92 additions & 0 deletions task/create-gitlab-release/0.2/create-gitlab-release.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: create-gitlab-release
labels:
app.kubernetes.io/version: "0.2"
annotations:
tekton.dev/pipelines.minVersion: "0.50.0"
tekton.dev/categories: Git
tekton.dev/tags: gitlab
tekton.dev/displayName: "create gitlab release"
tekton.dev/platforms: "linux/amd64"
spec:
description: >-
This `task` can be used to make a gitlab release.

params:
- name: TAG_NAME
description: Name of the tag.
type: string
- name: NAME
description: Name of the release.
type: string
- name: DESCRIPTION
type: string
description: Short description of the release.
default: ""
- name: RELEASE_REF
type: string
description: Required in the case of Gitlab, It can be a commit SHA, another tag name, or a branch name.
default: master
- name: PROJECT_ID
type: string
description: Project id for gitlab project.
- name: UPLOAD_ASSET_NAME
type: string
description: Name of the asset to be uploaded.
default: ""
- name: UPLOAD_ASSET_URL
type: string
description: Uplaod URL for the hosted asset.
default: ""
- name: GITLAB_TOKEN_SECRET
type: string
description: Name of the secret holding the gitlab-token.
default: gitlab-token
- name: GITLAB_TOKEN_SECRET_KEY
type: string
description: Name of the secret key holding the gitlab-token.
default: GITLAB_TOKEN
steps:
- name: create-release
image: registry.access.redhat.com/ubi8/ubi-minimal:8.2@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6
script: |
#!/usr/bin/env bash

# Creating asset json if file is to be uploaded with gitlab release
#
assetJson=""
# Checking whether asset is provided to upload with release or not.
#
if [ "$(params.UPLOAD_ASSET_NAME)" != "" ] || [ "$(params.UPLOAD_ASSET_URL)" != "" ]; then
assetJson=',"assets": {"links": [{"name": "$(params.UPLOAD_ASSET_NAME)","url": "$(params.UPLOAD_ASSET_URL)"}]}'
fi

# Creating the api post data
#
generate_api_post_data()
{
cat <<EOF
{
"name": "$(params.NAME)",
"tag_name": "$(params.TAG_NAME)",
"description": "$(params.DESCRIPTION)",
"ref": "$(params.RELEASE_REF)"
$assetJson
}
EOF
}

echo "Creating release $(params.TAG_NAME)"

curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN:$TOKEN" \
--data "$(generate_api_post_data)" \
--request POST https://gitlab.com/api/v4/projects/$(params.PROJECT_ID)/releases

env:
- name: TOKEN
valueFrom:
secretKeyRef:
name: $(params.GITLAB_TOKEN_SECRET)
key: $(params.GITLAB_TOKEN_SECRET_KEY)
26 changes: 26 additions & 0 deletions task/create-gitlab-release/0.2/samples/run.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: create-gitlab-release-run
spec:
taskRef:
name: create-gitlab-release
params:
- name: TAG_NAME
value: "v1.0.0"
- name: NAME
value: first release
- name: DESCRIPTION
value: This is first release
- name: PROJECT_ID
value: "18587362"
- name: RELEASE_REF
value: master
- name: UPLOAD_ASSET_NAME
value: test.yaml
- name: UPLOAD_ASSET_URL
value: https://google.com
- name: GITLAB_TOKEN_SECRET
value: gitlab-token
- name: GITLAB_TOKEN_SECRET_KEY
value: GITLAB_TOKEN
7 changes: 7 additions & 0 deletions task/create-gitlab-release/0.2/samples/secret.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
apiVersion: v1
kind: Secret
metadata:
name: gitlab-token
type: Opaque
stringData:
GITLAB_TOKEN: $(personal-gitlab-token)
164 changes: 164 additions & 0 deletions task/git-cli/0.5/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,164 @@
# Git Task

This `Task` is Git task to work with repositories used by other tasks
in your Pipeline.

## `git-cli`

This [task](../0.3/git-cli.yaml) can be used to perform `git operations`.
All git commands can be found [here](https://git-scm.com/docs).

Command that needs to be run can be passed as a script to the task.

### Workspaces

* **source**: A workspace that contains the fetched git repository.
* **input**: An optional workspace that contains the files that need to be added to git. You can
access the workspace from your script using `$(workspaces.input.path)`, for instance:

cp $(workspaces.input.path)/file_that_i_want .
git add file_that_i_want
# etc

* **ssh-directory**: An optional workspace to provide SSH credentials. At
minimum this should include a private key but can also include other common
files from `.ssh` including `config` and `known_hosts`. It is **strongly**
recommended that this workspace be bound to a Kubernetes `Secret`.
For details on the correct format of the files in this Workspace
see [Using SSH credentials](#using-ssh-credentials) below.

* **basic-auth**: An optional workspace containing `.gitconfig` and
`.git-credentials` files. This allows username/password/access token to be
provided for basic auth.

It is **strongly** recommended that this workspace be bound to a Kubernetes
`Secret`. For details on the correct format of the files in this Workspace
see [Using basic-auth Credentials](#using-basic-auth-credentials) below.

### Parameters

* **BASE_IMAGE**: The base image for the task.
(_default_: `alpine/git:latest`)
* **GIT_USER_NAME**: Git user name for performing git operation.
* **GIT_USER_EMAIL**: Git user email for performing git operation.
* **GIT_SCRIPT**: The git script to run. (_required_)
* **VERBOSE**: Log the commands that are executed during `git-cli`'s operation. (_default_: true)
* **USER_HOME**: Absolute path to the user's home directory. Set this explicitly if you are running the image as a non-root user or have overridden
the gitInitImage param with an image containing custom user configuration. (_default_: "/root")

### Results

* **commit**: The precise commit SHA after git operation is performed.

### Platforms

The Task can be run on `linux/amd64`, `linux/s390x` and `linux/ppc64le` platforms.

### Usage

This task needs authentication to git in order to push after the git operation.

After creating the task, you should now be able to execute `git` commands by
specifying the command you would like to run as the `GIT_SCRIPT` param.

`Example`:

```yaml
params:
- name: GIT_SCRIPT
value: |
git init
git remote add origin https://github.com/kelseyhightower/nocode
git pull origin master
```

## Using SSH credentials

This Task supports fetching private repositories using SSH credentials.

If you are a bit rusty on your SSH and don't know what a typical .ssh directory should look like,
there are tons of good guides to be found online, see for instance [this article by Digital Ocean](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys).

1. Bind an `ssh-directory` workspace to this Task.
The workspace should contain private keys (e.g. `id_rsa`), `config`
and `known_hosts` files - anything you need to interact with your git remote
via SSH. It's **strongly** recommended that you use Kubernetes `Secrets` to
hold your credentials and bind to this workspace.

In a TaskRun that would look something like this:

```yaml
kind: TaskRun
spec:
workspaces:
- name: ssh-directory
secret:
secretName: my-ssh-credentials
```

And in a Pipeline and PipelineRun it would look like this:

```yaml
kind: Pipeline
spec:
workspaces:
- name: ssh-creds
# ...
tasks:
- name: use-git-cli
taskRef:
name: git-cli
workspaces:
- name: ssh-directory
workspace: ssh-creds
# ...
---
kind: PipelineRun
spec:
workspaces:
- name: ssh-creds
secret:
secretName: my-ssh-credentials
# ...
```

The `Secret` would appear the same in both cases - structured like a `.ssh`
directory:

```yaml
kind: Secret
apiVersion: v1
metadata:
name: my-ssh-credentials
data:
id_rsa: # ... base64-encoded private key ...
known_hosts: # ... base64-encoded known_hosts file ...
config: # ... base64-encoded ssh config file ...
```

Including `known_hosts` is optional but strongly recommended. Without it
the `git-cli` Task will blindly accept the remote server's identity.

## Using basic-auth Credentials

**Note**: It is strongly advised that you use `ssh` credentials when the
option is available to you before using basic auth.

To support basic-auth this Task exposes an optional `basic-auth` Workspace.
The bound Workspace must contain a `.gitconfig` and `.git-credentials` file.
Any other files on this Workspace are ignored. A typical `Secret` containing
these credentials looks as follows:

```yaml
kind: Secret
apiVersion: v1
metadata:
name: my-basic-auth-secret
type: Opaque
stringData:
.gitconfig: |
[credential "https://<hostname>"]
helper = store
.git-credentials: |
https://<user>:<pass>@<hostname>
```
Loading
Loading