Link application repository PR and the PipeCD deployment related to it.

[ffjlabo]

What would you like to be added:

When separating the app code repo and manifests repo by using event watcher,
it would be nice to link the app repo PR and PipeCD deployment.

Why is this needed:

There are some use cases.
For example,

• rollback the app code repo quickly when the incident occurs.
• record the time from when a PR is closed until the PipeCD deployment is triggered

[Warashi]

I investigated the plan to solve this issue.

Pre-condition:

• The event operation flow is as follows, so we can only use the commit information of the manifest repository for the deployment operation.
  1. Commit to the Application repository
  2. pipe-cd/actions-event-register is invoked
     • In this action, pipectl event register is invoked
  3. piped receives the event from the control plane server and commits to the manifest repository
  4. piped pull the manifest repository and detect changes
  5. piped deploy changes to the infrastructure, we can use only the information of the pulled commits.
• We can use the text/template feature in the commit message through the event GIT_UPDATE; this is undocumented.

  • pipecd/pkg/app/piped/eventwatcher/eventwatcher.go

    Lines 772 to 789 in 713fb03

    	// parseCommitMsg parses event watcher's commit message.
    	// Currently, only {{ .Value }} and {{ .EventName }} are supported.
    	func parseCommitMsg(msg string, args argsTemplate) string {
    	if msg == "" {
    	return fmt.Sprintf(defaultCommitMessageFormat, args.Value, args.EventName)
    	}
    	t, err := template.New("EventWatcherCommitMsgTemplate").Parse(msg)
    	if err != nil {
    	return msg
    	}
    	buf := new(strings.Builder)
    	if err := t.Execute(buf, args); err != nil {
    	return msg
    	}
    	return buf.String()
    	}

Plan:

Overview:

Pass the context information through actions-event-register -> pipectl -> control-plane-server -> piped -> manifest repo -> piped

Detail

1. collect GitHub repo/commit context in actions-event-register
2. create a new option --context to the pipectl and pass contexts to it
3. add map<string,string> context here and pass contexts

   • pipecd/pkg/app/server/service/apiservice/service.proto

     Lines 228 to 232 in 713fb03

     	message RegisterEventRequest {
     	string name = 1 [(validate.rules).string.min_len = 1];
     	string data = 2 [(validate.rules).string.min_len = 1];
     	map<string,string> labels = 3 [(validate.rules).map.keys.string.min_len = 1, (validate.rules).map.values.string.min_len = 1];
     	}

4. add map<string,string> context here and store contexts

   • pipecd/pkg/model/event.proto

     Lines 29 to 55 in 713fb03

     	message Event {
     	reserved 7;
     	// The generated unique identifier.
     	string id = 1 [(validate.rules).string.min_len = 1];
     	// The name of event.
     	string name = 2 [(validate.rules).string.min_len = 1];
     	// The data of event.
     	string data = 3 [(validate.rules).string.min_len = 1];
     	// The ID of the project this event belongs to.
     	string project_id = 4 [(validate.rules).string.min_len = 1];
     	// The key/value pairs that are attached to event.
     	// This is intended to be used to specify additional attributes of event.
     	map<string,string> labels = 5;
     	// A fixed-length identifier consists of its own name and labels.
     	string event_key = 6 [(validate.rules).string.min_len = 1];
     	// The handle status of event.
     	EventStatus status = 8 [(validate.rules).enum.defined_only = true];
     	string status_description = 9;
     	// Unix time when the event was handled.
     	int64 handled_at = 13;
     	// Unix time when the event was created.
     	int64 created_at = 14 [(validate.rules).int64.gt = 0];
     	// Unix time of the last time when the event was updated.
     	int64 updated_at = 15 [(validate.rules).int64.gt = 0];
     	}

5. add Context map[string]string here and pass contexts

   • pipecd/pkg/app/piped/eventwatcher/eventwatcher.go

     Lines 766 to 770 in 713fb03

     	// argsTemplate represents a collection of available template arguments.
     	type argsTemplate struct {
     	Value string
     	EventName string
     	}

6. add a document about the text/template feature of the GIT_UPDATE event
7. finally, users can use {{ .Context.GITHUB_SHA }} or something like this in the commit message format through the GIT_UPDATE event config so that users can use the application repository context in the deployment SCRIPT_RUN stage or from the webhook.