• Now
  • SHA is 0000000000000
• Desired
  • Target SHA for the tag

A part of #7

• Use Tekton's Custon Task feature (from v0.19.0) to implement approval task

Public GitHub/GitLab APIs have rate limits. We need to handle the limit exceed situations.

GitHub/GitLab APIs support paginations and only return fixed amount of items per request.
The client should be able to handle the pagination

Also, public GitHub/GitLab APIs have rate limits. We need to handle the limit exceed situations.

Users need detailedMessage (i.e., pipelineRun's message) to check how the pipeline is running, which cannot be referred from the current message.

What we need

• ConfigMap tekton-pipelines/feature-flags > enable-custom-tasks to be true
• On operator start-up, check if it is set, if not, set it

• We can make a ConfigMap reconciler, to reflect the ConfigMap change in real-time

like tide, add BaseSHA: xxxx string at the end of the description

• Emit cloud event when the state of IntegrationJobs change (https://github.com/cloudevents/spec)

Currently, config controller is tightly coupled with controller (a.k.a. manager).

As we are implementing blocker, which is planned to be an independent binary itself, it should be able to parse its own configs from config map.

The secrets should be added to the service account

GitHub/GitLab APIs support paginations and only return fixed amount of items per request.
The client should be able to handle the pagination

It is required to test multiple PRs at once (i.e., IntegrationJob's jobs are executed against the code where all the target PRs are merged into), to reduce time consumed for re-testing before block-merge.

What we need

• Commenting for pull requests, with /test or /test <job name> should trigger the jobs
• /lgtm or /approve should be implemented (those comments not actually approves the pull request, but labels it so that merge automation module(#11) decides if it's mergeable or not)

Maybe we can use https://github.com/uber-go/zap/blob/master/FAQ.md#does-zap-support-log-rotation

• Emit k8s events when the state of IntegrationJobs change
• (If possible) Emit cloud event when the state of IntegrationJobs change (https://github.com/cloudevents/spec)

• Desired Behavior

  • Whenever the configmap extension-apiserver-authentication of kube-system namespace is updated, restart API server with trusting the updated CA.

• Current Behavior

  • If the configmap is updated, error log occurs on service discovery

Workspace (= PersistentVolumeClaim) to be shared between jobs is needed

What do we need

• PipelineRun creation logic from IntegrationJob
• Logic to report current status of given PipelineRun to remote git server

Implementation Goal

What do we need

• Validate token given to IntegrationConfig spec
• Register webhook to remote git server when IntegrationConfig is created
• Secret (has git/docker credentials), ServiceAccount (with the secret, used for running PipelineRun)

Implementation Goal

Maybe we can refer to tide(https://github.com/kubernetes/test-infra/blob/master/prow/cmd/tide/config.md)

Part of #11

What do we need

• Scheduling policy to prevent resource hogging
• Scheduling logic from IntegrationJob to PipelineRun

Implementation Goal

• Triggered by IntegrationJob controller

• Desired Behavior

  • Approval result mail is sent the sender (who pushed or requested pull request)

• Current Behavior

  • Approval result mail is sent to the approvers

• Possible Solution

  • Modify spec.sender filed of Approval object as an object with keys name and email.
  • Modify spec.refs.sender field of IntegrationJob object as an object with keys name and email.
  • Modify git webhooks to parse sender email, by calling GitHub/GitLab's user APIs
  • Modify dispatcher to add email to IntegrationJob
  • Modify approval_run_controller to add email to Approval
  • Send approval results to Approval's sender.email

• Current Behavior
  • Same webhook can be registered repeatedly
• Possible Solution
  • List webhooks first and check if there exists one with identical options

What do we need

• git client interface
• GitHub/GitLab client that implements git client interface

Implementation Goal

• Webhook Header validation
  • Content-Type: application/json
  • (For GitHub) X-GitHub-Event should exist
  • (For GitLab) X-Gitlab-Event should exist
• Webhook Body validation
• Webhook parser to convert webhook body to common-struct
• API calls
  • Register webhook to git repository
  • Add commit status

• Use Tekton's Custon Task feature (from v0.19.0) to implement email task

• In order to detect IntegratinoJob deletion and call Schedule function
• Also, IntegrationJob controller must implement to sync JobPool

If one of the code owners comment /approve to a PR, then approved label should be set.

Also, if one of the code owners approve the PR by using git's approval feature, approved label should be set.

• Add image-build preset
• Add image-build-s2i preset

(Prerequisite for #189)

Currently, IntegrationJob does not have base (target branch's) SHA for presubmit jobs.
This is because GitLab's MergeRequest webhook payload does not contain it.

Maybe we should make a get request for target_branch to get the SHA (only for gitlab)

What do we need

• API handler for endpoint : /webhook/<Namespace>/<IntegrationConfig Name> - for git event webhook

Implementation Goal

• Get IntegrationConfig object and get git type → create git client for the type
• Call webhook validation function of the git client
• Convert the webhook body to common-struct → call dispatcher to create IntegrationJob

What do we need

• Logic to convert common webhook structure to IntegrationJob spec

Implementation Goal

• Filter out webhook bodies with event types other than push/pull_request
• Filter out jobs that does not match conditions specified in when

We need to support following scenarios.

Scenario 1

• A user want to trigger IntegrationConfig's jobs manually only, not via git events
• Then we do not need the admin acess token for registering webhook

For #13 (IntegrationConfig controller)

• Add logic to create Secret which follows tekton git credential config
• Add logic to create ServiceAccount which follows the same guide

For #9 (PipelineManager)

• Add ServiceAccountName when generating a PipelineRun