Proposal: Release Post Automation MVC

In order to support !33374 (merged) the following proposed process has been developed. Below is a description of the process at a high level, but it should be possible to completely automate this process when ready.

The goal of this process is to define a reliable way to determine if a feature is included in the monthly release, and make it easy to assemble the monthly release blog post.

Expected Inputs

The inputs necessary for this process come in the form of MRs created by PMs to describe the features their teams are building. These MRs follow a standardized process, which results in a single yaml file being added to a specific folder in www-gitlab-com. For example in %12.4: !32608 (merged). The content of these yaml files includes a issue_url value. We can use this value to trace the release post MR back to the original issue. We can also use the milestone associated with the MR to identify the current milestone.

In order to identify these MRs, they must be labeled with release post and ready to merge. This process will only pick up MRs with both labels.

Finding Related MRs

Having the issue_url for each feature, and the milestone from the MR, we can then use some logic to determine which MRs compose that feature for that milestone, and find their statuses.

Given this issue as an example, there are multiple related MRs, but only four of them have the %12.4 milestone. This process will only concern itself with related MRs for the given milestone. This is important because often times follow up tasks are still associated with an issue but prioritized in later milestones.

Determining Issue Status

Once the list of related MRs is retrieved, a couple checks must be performed to determine the status of the issue.

1. The first check will ensure that all the related MRs for the given milestone have been merged. If one or more have not been merged, it will be determined that the feature is not complete.

2. If all MRs have been merged, the next step will be to find the SHAs for each MR and query the ChatOps API for each SHA.

   1. If all of the queries return a status indicating they are currently running in production, then it will be determined that the feature is complete.
   2. If one or more of those queries return a status indicating that they are not currently running in production, it will be determined that the feature is not complete.

Completed Features

When a featured is determined to be complete, a label of in production will be added to the original release post MR indicating that MR can be merged and the feature should be expected in the next release.

Timeline

In order for this process to work a structured timeline will be defined. The release post MRs must be merged by the 17th of the month. In order to accommodate that timeline a feature freeze date for engineering will be defined to support a sufficient burn-in time on gitlab.com.

@jlenny @kencjohnston @dcroft @erushton @marin @clefelhocz1, this is my initial attempt at defining a process for Release Post Automation, please take a look and let me know what questions or feedback you have. Thanks!