kube-cicd / pipelines-feedback-core Goto Github PK

There should be a PFConfig and PipelineRun distinction based on label or annotation, so various controllers could not collide.
That would also make parallel beta testing of a controller possible on a single cluster.

Github as well as Gitlab supports "Releases" as an extension to tags. We may update those releases pages with links to deployed environments and with links to PRs.

Such feedback may increase visibility over what was released, when, and which GitOps change (PR) released the application to an environment.

The guide should consist of at least two parts:

• For controller developers
• For end users installing controller on the cluster and integrating it with their CI/CD flow

Enchancement proposal - on each commit there could be added a comment with the Pipeline status - optionally.

Configurable as follows:

---
apiVersion: pipelinesfeedback.keskad.pl/v1alpha1
kind: PFConfig
metadata:
    name: keskad-sample-1
spec:
    jobDiscovery: {}
data:
    jxscm.comment-commit-on-failure:   "true"   # defaults to "false"
    jxscm.comment-commit-on-success: "true"   # defaults to "false"

Make Store a user choice selectable in commandline.

Support Pipeline status comments in jxscm implementation

Hi,

WASM could be used as a Feedback Receiver and Provider adapters, so people may easily change Pipelines Feedback behavior without making forks.

Todo: Research how it could be made with https://github.com/tetratelabs/wazero

CI/CD Pipelines as a part of continuous integration process are used for testing the software. Testing frameworks like PHPUnit, PyTest or jUnit supports reporting.

Kubernetes-native solutions like Tekton or Argo Workflows does not have a presentation layer that could easily show a nice report of executed tests, therefore I come with a following proposal.

• API) Pipelines Feedback Controller can expose a HTTP API allowing to send a notification message to destination PR/MR/commit/slack/other during the Pipeline execution.

• Authentication) The controller could generate a temporary API token after receiving Pipeline starting signal and keep that token in a store (e.g. redis)

• Credentials) Mutation Webhooks could be used to inject temporary token by a controller into the TaskRun's environment variable

• jUnit implementation) Example implementation could be created in a separate repository - a CLI tool written in Go that would parse junit/xunit formatted report and contact Pipelines Feedback controller via API to send the notification

In order to make sure PFConfig changes are merged as expected there could be an optional priorityWeight field that describes how important is particular PFConfig .

PFConfigs could be sorted by priorityWeight ascending, so the PFConfig with highest value wins in the merging order.

---
apiVersion: pipelinesfeedback.keskad.pl/v1alpha1
kind: PFConfig
metadata:
    name: keskad-sample-1
spec:
    jobDiscovery: {}
    priorityWeight: 100 # defaults to 0
data:
    # ...

Use case (Gitlab):

• We want to test every commit, not only a Pull Request commit
• Using Push Event we don't get PR ID, but every commit is triggering the Pipeline
• Using Pull Request Push event we get PR ID, but only for commits belonging to a PR

Solution: A proposal to add a feature toggle to obtain PR id dynamically

Add a interface method to allow implementing logs collection. This may be helpful in case of attaching logs to notifications or merge request comments

ERRO[2023-11-06T09:51:36+01:00] cannot update feedback retriever: cannot update commit status: Bad Request  name=sample-cicd/sample-springboot11-preview-bwxx8 request=b0cda7b6-7c81-11ee-95bc-902e16dea917

It seems it may be related with commit status, some statuses are passing, some are not.
For example - a failed pipeline is not reported.

Support Slack as Feedback Receiver, so the Pipelines could be reported as updated slack messages.

Example:

logs-enabled: "false"   # this does not work
jxscm.git-kind: gitlab

Expectations:

Global configuration keys would be overwritten in given namespace, where global key is defined in PFConfig - e.g. logs-enabled

GIVEN I annotate Pipeline stage with pipelinesfeedback.keskad.pl/stage-complete: sonar
WHEN Pipeline stage completes or fails
THEN MR/PR label is added or removed

Idea is to make it a generic mechanism stage-complete which in JX SCM can mean to add a label, but on other feedback receiver e.g. Slack it may mean adding a reaction emot icon or writing a message to a thread.

JX SCM could have a configuration option - a feature toggle to enable this feature:

jxscm.on-stage-complete: label

Support matrix.im as a Feedback Receiver

For simplicity there could be a Redis object templated optionally.

In order to make a first release we need a way to package the controller.
Easiest way I think would be to make a customizable Helm Chart which can swap images of adapters (e.g. pipelines-feedback-tekton can use the same chart)