## Pipelines-as-Code

### Functionality/features that would be nice to have

1. Parameter mapping from webhook payload
- Currently, there are only a subset of parameters from the webhook payload that can be parameterized for a pac pipeline run
- A lot of our pipelines use additional values from the webhook payload as parameters, which are unavailable. In order to get those missing values, we have to add additional tasks to the pipeline to retrieve said values from an outside source (github api). Adding a bunch of individual values and figuring out said values across different source control systems can be tedious. Would it be possible to send the entire webhook payload down as a variable named payload, so we can source out whatever missing information is needed from the payload?
- Some missing examples:
- Base sha
- PR: body.pull_request.base.sha
- Push: body.before
- Github event (header.X-GitHub-Event)
- Github repo full name (body.repository.full_name)

Notes:
- Accepted
- Action: https://issues.redhat.com/browse/SRVKP-2517 Priortise

2. CEL expression overlay parameters
- Some of our triggers are using CEL expression overlays to create parameters, which are then passed down to the pipeline runs through TriggerBindings and TriggerTemplates. It would be helpful if there was a way to accomplish this, similar to the `pipelinesascode.tekton.dev/on-cel-expression` functionality

Notes:
- Action: Clarify what are they using CEL for in triggers ?

3. `pipelinesascode.tekton.dev/on-cel-expression` is limited
- This functionality only supports as subset of parameters that can be referenced for cel expression. It would be helpful if more information from the webhook payload could be queried. Maybe even have the full payload available that can be referenced in the cel expression

Notes:

4. PipelineRun output logging
- After a pipeline run is completed, the checks tab in Github Enterprise only shows a list of tasks and each task's status. It does not contain the output from said tasks. When the pipeline run is cleaned up, we lose the output from the cleaned up runs. It would be helpful if:
- There was a built-in method for storing pipeline results and logs to an external source, like a storage bucket, etc
- The output from each task was added alongside the task status in the details on the Checks tab in Github
- If we do not want to log every task's output, then possibly add a way to specify which tasks should have their output logged to the checks tab

Notes:
- EPIC: https://issues.redhat.com/browse/SRVKP-2490
- Action: Clarify Only failures or all output ?

5. Support for pipelines in pipelines: Support for calling a pipeline within a pipeline dynamically

Notes:
- Understand usecase from Ford
- Dependecy control

6. Clarity on concurrent/parallel pipeline runs

- How is the pipeline run execution order determined if there are multiple pipelines present in the `.tekton` folder and concurrency is enabled?
- For example, if you have three different pipelines present in the .tekton folder that all trigger when a PR is opened, and the `concurrency_limit` is set to 1, then how is the execution order determined? From our testing, it seems to be completely random.
- Is there a way to control the execution order?

Notes:
- The order of execution is random currently.
- Advanced concurrency control - https://issues.redhat.com/browse/SRVKP-2310
- Action: Discuss more with Ford

### Issues

1. In order to pull down tasks from the external tekton hub, we had to add our internal proxy servers through environment variables in the `pipelines-as-code-controller` deployment
- It would be helpful if the proxy configuration was parameterized, possibly in the config map?
- Without the proxy config, this is the error we receive: `There was an issue validating the commit: "error getting remote task maven: could not fetch remote task maven, hub API returned: Get "https://api.hub.tekton.dev/v1/resource/tekton/task/maven\": dial tcp: lookup api.hub.tekton.dev on 172.30.0.10:53: no such host"`

Notes:
- Action Item: Clarify from Ford on how they are configuring proxy in cluster.
- Error points to DNS resolution problem.
- Proxy Setting at operator level ? Yes. Pass as env to operator deployment/subscription

2. We were unable to use our own internal tekton hub because we do not have a catalog named `tekton` on said hub. Our hub consists of multiple catalogs owned by multiple teams, each catalog is in it's own git repository
- We submitted an upstream PR that was merged in, so we can change the default catalog to something other than tekton, which does not appear to be released yet?
- Are alternate solutions to this being investigated, so the catalog name can be inferred from the syntax from the remote task reference?

Notes:
- Multiple catlogs with different name is not supported yet.
- Syntax: catalog1::git-clone catalog2::git-clone2
- Action: Add a epic

3. If we open a PR and the `Pipelines as Code CI` status check fails due to an internal pipelines as code configuration error, then we are unable to clear the failed `Pipelines as Code CI` status check after fixing the configuration error
- The only way we were able to get around the failed status check is to move our code to a new branch and open a new PR from the new branch
- Closing and re-opening the failed PR, running it again via /retest, or running it again via re-run from the Checks tab will not clear the failed status

Notes:
- Might be solved by git commit --ammend --edit && git push --force remote branch
- Action: Clarify from Ford
- What PAC configuration error ?

4. When configuring a pipeline run for a **push** event, the target_branch has to be specified as `/refs/heads/main`. If we have the target_branch referenced as `main`, then the pipeline run never starts. We use Github Enterprise, if that matters

Notes:
- Action Item: File a bug, E2E Test
- Applicable for all git providers
- Document this behaviour (before PAC GA)

6. When configuring a pipeline run for a **pull_request** event, the target_branch has to be specified as `main`. If we have the target_branch referenced as `refs/heads/main`, then the pipeline run never starts. We use Github Enterprise, if that matters

Notes:

### Roadmap

If available, it would be helpful to see a short and long-term roadmap for Pipelines-as-Code.