Commit 9165d5d7 authored by Jason Lenny's avatar Jason Lenny

Fix issues with renamed stage labels

parent 734c0846
......@@ -21,7 +21,7 @@
# - reporter: pm1 # GitLab handle of the user adding the feature block in the list (not the feature author)
# - stage: stagename # DevOps stage the feature belongs to
# Example => stage: secure
# lowercase, omit the leading 'devops:'
# lowercase, omit the leading 'devops::' part of the label
# see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md#stage-labels
# - issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12345' # link to the issue on GitLab.com where the feature is discussed and developed - required but replaceable with epic_url or mr_url
# - issueboard_url: 'https://gitlab.com/group/project/boards/123?=' # link to the issue board for the feature (not required)
......
......@@ -202,7 +202,7 @@ module Generators
issues = []
edition.each do |project|
issues += project.milestone_direction_issues(ms['title'], stages.map { |n| "devops:" + n })
issues += project.milestone_direction_issues(ms['title'], stages.map { |n| "devops::" + n })
end
next if issues.empty?
......@@ -227,7 +227,7 @@ module Generators
issues.each do |issue|
stages.each do |stage|
buckets[stage] = [] if buckets[stage].nil?
buckets[stage] << issue if issue['labels'].include?("devops:#{stage}")
buckets[stage] << issue if issue['labels'].include?("devops::#{stage}")
end
end
......@@ -286,22 +286,22 @@ module Generators
# 'wiki',
[
'devops:manage',
'devops:plan',
'devops:create',
'devops:verify',
'devops:package',
'devops:release',
'devops:configure',
'devops:monitor',
'devops:secure',
'devops::manage',
'devops::plan',
'devops::create',
'devops::verify',
'devops::package',
'devops::release',
'devops::configure',
'devops::monitor',
'devops::secure',
'HA',
'Cloud Native',
'moonshots'
].each do |label|
output[label] = label_list(label)
end
output['devops:distribution'] = label_list('direction', exclude: ['HA', 'Cloud Native'], editions: Array(edition[2]))
output['devops::distribution'] = label_list('direction', exclude: ['HA', 'Cloud Native'], editions: Array(edition[2]))
['GitLab Starter', 'GitLab Premium', 'GitLab Ultimate'].each do |tier|
output[tier] = tier_list(tier)
......@@ -324,8 +324,8 @@ module Generators
'code review',
'web ide',
'license management',
'devops:package',
'devops:release',
'devops::package',
'devops::release',
'application control panel',
'infrastructure configuration',
'issues',
......@@ -342,8 +342,8 @@ module Generators
].each do |label|
output[label] = product_vision_list(label)
end
output['ci'] = product_vision_list('devops:verify', ['Secure'])
output['security testing'] = product_vision_list('devops:secure', ['license management'])
output['ci'] = product_vision_list('devops::verify', ['Secure'])
output['security testing'] = product_vision_list('devops::secure', ['license management'])
puts
......
......@@ -13,4 +13,4 @@ feedback on any of these items you're more than welcome to jump into
the discussion. Our vision and product are truly something we build
together!
<%= wishlist["devops:#{stage}"] %>
<%= wishlist["devops::#{stage}"] %>
......@@ -133,7 +133,7 @@ and later pulled for testing and deployment.
## Package
<i class="vision-item far fa-check-square" aria-hidden="true"></i> [Container Registry](https://docs.gitlab.com/ee/user/project/container_registry.html)<br>
<%= product_vision['devops:package'] %>
<%= product_vision['devops::package'] %>
## Release
......@@ -146,7 +146,7 @@ scripts in the `deploy` stage in `.gitlab-ci.yml`. We will go further.
<i class="vision-item far fa-check-square" aria-hidden="true"></i> [Deployment history](https://docs.gitlab.com/ee/ci/environments.html#viewing-the-deployment-history-of-an-environment)<br>
<i class="vision-item far fa-check-square" aria-hidden="true"></i> [Deploy boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html) <kbd>Premium</kbd><br>
<i class="vision-item far fa-check-square" aria-hidden="true"></i> [Canary deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html) <kbd>Premium</kbd><br>
<%= product_vision['devops:release'] %>
<%= product_vision['devops::release'] %>
## Configure
......
......@@ -49,6 +49,6 @@ Like most GitLab backened teams we spend a lot of time working in Rails on the m
### On issues
Issues the Release team works on have the ~"Release" label. Issues that contribute to the release stage of the devops toolchain have the ~"devops:release" label.
Issues the Release team works on have the ~"Release" label. Issues that contribute to the release stage of the devops toolchain have the ~"devops::release" label.
......@@ -49,6 +49,6 @@ Like most GitLab backened teams we spend a lot of time working in Rails on the m
### On issues
Issues the Verify team works on have the ~"Verify" label. Issues that contribute to the verify stage of the devops toolchain have the ~"devops:verify" label.
Issues the Verify team works on have the ~"Verify" label. Issues that contribute to the verify stage of the devops toolchain have the ~"devops::verify" label.
......@@ -1163,9 +1163,9 @@ there is a single group for `Manage`, but will be splitting into `control` and `
To prepare for splitting a Stage into multiple Groups, we should:
1. Update `categories.yml` and `stages.yml`, assigning each Group a set of Categories
1. Ensure all issues remain labelled with the Stage name, like `devops:manage`
1. Ensure all issues remain labelled with the Stage name, like `devops::manage`
1. Ensure all issues also have a group label, like `Control` or `Framework`
1. Prior to the new groups being formed, the PM and EM prioritize the shared `devops:manage` backlog
1. Prior to the new groups being formed, the PM and EM prioritize the shared `devops::manage` backlog
Once the first PM or EM is hired, the new Group should be formed:
......@@ -1194,9 +1194,9 @@ When GitLab decides to address additional needs within the single application, a
address additional needs beyond what `Secure` focuses on.
When a new Stage is added, and its Group has yet to be formed, we should:
1. Ensure all issues for the new Stage are assigned with the Stage labels, like `devops:defend` and `Defend`
1. Ensure all issues for the new Stage are assigned with the Stage labels, like `devops::defend` and `Defend`
1. Identify an existing Group, like `Secure`, which will be initially responsible for the new Stage
1. The existing Group will prioritize across a common backlog of both Stages, in this example `devops:defend` and `devops:secure`
1. The existing Group will prioritize across a common backlog of both Stages, in this example `devops::defend` and `devops::secure`
1. Update `categories.yml` and `stages.yml`, listing the new Stage with the members of the existing responsible Group
Once the first PM or EM is hired, a new Group for the Stage should be formed:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment