Welcome to the ChatOps/release-tools task naming bikeshed!
Right now we've got a structure like this:
graph LR
subgraph ChatOps
co-pick["cherry_pick VERSION"]
co-prepare["prepare VERSION"]
co-publish["publish VERSION"]
co-qa["qa_issue FROM..TO"]
co-release-issue["release_issue VERSION"]
co-tag["tag VERSION"]
end
subgraph release-tools
rt-pick["cherry_pick[version]"]
rt-prepare["patch_merge_request[version]"]
rt-publish["publish[version]"]
rt-qa["qa_issue[from,to]"]
rt-qa-security["security_qa_issue[from,to]"]
rt-monthly-issue["monthly_issue[version]"]
rt-patch-issue["patch_issue[version]"]
rt-security-patch-issue["security_patch_issue[version]"]
rt-tag["tag[version]"]
rt-security-tag["security_tag[version]"]
end
co-pick --> rt-pick
co-prepare--> rt-prepare
co-publish --> rt-publish
co-qa --> rt-qa
co-qa -->|--security| rt-qa-security
co-release-issue -->|X.Y.0| rt-monthly-issue
co-release-issue -->|X.Y.Z| rt-patch-issue
co-release-issue -->|--security| rt-security-patch-issue
co-tag --> rt-tag
co-tag -->|--security| rt-security-tag
The following release-tools commands have no ChatOps alternative (and plan to stay that way):
close_expired_qa_issues
freeze
helm:tag_chart
release_managers:auth
release_managers:sync
spec
upstream_merge
The following release-tools commands are likely to need ChatOps versions:
-
green_master:all
,green_master:ce
,green_master:ee
-
prepare:monthly
(create themonthly_issue
, createPick into
label) -
prepare:security
(createsecurity_patch_issue
s for the last three monthly releases) -
security:merge
(merge security MRs on dev) -
security:validate
(validate security MRs on dev) -
sync
(after https://gitlab.com/gitlab-org/release/framework/issues/41)
Which gets us into a weird spot. ChatOps already has a prepare
command, which would be the natural place for the two prepare
tasks, but then the command would be doing wildly different things depending on context, which gets confusing.
Edited by Robert Speicher