# Managing Pipes

## Pipekit Web UI

To create a new Pipe, go to the [Pipes tab in Pipekit](https://pipekit.io/pipes) and click the `+ Add pipe` button.

From here, choose the Organization the Pipe will belong to, the repo containing the Workflow yaml, and provide a human-friendly name and description.

You can choose to permit the running Workflow to access the git repository containing the Workflow yaml. This is useful if the workflow itself needs to access the git repository, for example to obtain stored code. To do this, tick `Grant workflow repository pull access`. For more information, refer to the [Grant workflow repository pull access](#grant-workflow-repository-pull-access) section.

You should then choose the [run/sync conditions](https://docs.pipekit.io/pipekit/pipes/managing-pipes/run-sync-conditions) for the Pipe. These are the git events that trigger the Pipe to run or a CronWorkflow to sync to your cluster.

### Grant workflow repository pull access

By checking `Grant workflow repository pull access`, you can grant a Workflow access to the git repository containing the Workflow yaml. This is done by automatically generating a ssh key and adding it to your git provider. The key is then injected into your cluster as a secret and mounted to your workflow at runtime for you you to use.

The generated key is mounted into the `/root` directory of your containers, and is available at the path `/root/.ssh/ssh-deploy-key` for both Github and Gitlab.

Here is a simplified example of how you could use the key to access a private repository in your workflow:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: clone-repo-
spec:
  entrypoint: clone-repo
  volumeClaimTemplates:
  - metadata:
      name: code
    spec:
      accessModes: [ "ReadWriteMany" ]
      storageClassName: nfs
      resources:
        requests:
          storage: 1Gi
  templates:
  - name: clone-repo
    container:
      image: alpine
      command:
        - sh
        - -c
        - |
          apk --update add openssh-client git
          eval `ssh-agent -s`
          mkdir -p /workdir/src/github.com/my_org
          cd /workdir/src/github.com/my_org
          ssh-add /root/.ssh/ssh-deploy-key
          ssh-keyscan github.com > /root/.ssh/known_hosts
          git config --global --add safe.directory '*'
          git clone git@github.com:my_org/my_repo.git
          cd my_repo
          git checkout $GIT_COMMIT
      volumeMounts:
      - name: code
        mountPath: /workdir
      resources:
        requests:
          memory: 1Gi
          cpu: 100m
```

{% hint style="info" %}
SSH keys are only made available to the Workflow that is triggered by the Pipe. If you have a Workflow that triggers another Workflow or uses workflowTemplates, the keys will not be passed to the second Workflow, or the workflowTemplate.
{% endhint %}

## Pipekit CLI

You can submit a Pipe to Pipekit using the Pipekit CLI. For more information, refer to the [Pipekit CLI documentation](https://docs.pipekit.io/cli#submitting-a-workflow).

{% hint style="info" %}
You cannot grant workflow repository pull access, or choose Run/Sync Conditions when submitting a Pipe via the CLI.
{% endhint %}

## Disabling a Pipe

If you wish for a Pipe to no longer run, you can disable it. To disable a pipe, you can toggle the switch on the Pipe. This action will prevent any further runs of the Pipe from being triggered. If you change your mind, you can re-enable the Pipe by toggling the switch back on.

## Deleting a Pipe

If you wish to delete a Pipe, go to the Pipe UI, and then the settings tab, then click the `Delete` button. You will be asked to confirm the deletion.

{% hint style="warning" %}
Deleting a Pipe will also delete all Runs and logs associated with the Pipe. Everything associated with the Workflow will be lost when a Pipe is deleted.
{% endhint %}