Add variable removal

Be sure to link this MR to the relevant issues.

• Deprecation issue: #352957 (closed)
• Removal issue: #404533 (closed)
• MR that removed (or will remove) the feature: !120050 (merged)

If there is no relevant deprecation issue, hit pause and:

• Review the process for deprecating and removing features.
• Connect with the Product Manager DRI.

Removals must be announced as deprecations at least 2 milestones in advance of the planned removal date.

If the removal creates a breaking change, it can only be removed in a major "XX.0" release.

By the 10th: Assign this MR to these team members as reviewers, and for approval:

• Required:
  • Product Group Manager or Director: @PM
  • Engineering Manager: @EM
  • Technical writer: @TW
• Optional:
  • Product Designer(s): @ProductDesigners
  • Product Marketing: @PMM

By 7:59 PM UTC 15th (11:59 AM PT): EM/PM assigns this MR to the TW reviewer for final review and merge: @EM/PM

By 7:59 AM UTC 18th (11:59 PM PT 17th): TW Reviewer updates Docs by merging this MR to master: @TW

---

Please review:

• The definitions of "Deprecation", "End of Support", and "Removal".
• The guidelines for removals.

EM/PM release post item checklist

• Set yourself as the Assignee, meaning you are the DRI.
• If the removal is a breaking change, add label breaking change.
• Follow the process to create a removal YAML file.
• Make sure that the milestone dates are based on the dates in Product milestone creation.
• Add reviewers by the 10th.
• When ready to be merged and not later than the 15th, add the ~ready label and @ message the TW for final review and merge.
  • Removal notices should not be merged before the code is removed from the product. Do not mark ~ready until the removal is complete, or you are certain it will be completed within the current milestone and released. If PMs are not sure, they should confirm with their Engineering Manager.

Reviewers

When the content is ready for review, the Technical Writer and Engineering Manager must review it. Optional reviewers can include Product Marketing, Product Design, and the Product Leaders for this area. Use the reviewers feature for all reviews. Reviewers will approve the MR and remove themselves from the reviewers list when their review is complete.

• (Recommended) PMM
• (Optional) Product Designer
• (Optional) Group Manager or Director
• Required review and approval: Technical Writer designated to the corresponding DevOps stage/group.

Tech writer review

The TW should review according to the criteria listed below. Review a removal MR with the same process as regular docs MRs. Add suggestions as needed, @ message the PM to inform them the first review is complete, and remove yourself as a reviewer if it's not yet ready for merge.

Removal notices should not be merged before the code is removed from the product.

Expand for Details

• Title:
  • Length limit: 7 words (not including articles or prepositions).
  • Capitalization: ensure the title is sentence cased.
• Dates:
  • Make sure that the milestone dates are based on the dates in Product milestone creation.
• Consistency:
  • Ensure that all resources (docs, removal, etc.) refer to the feature with the same term / feature name.
• Content:
  • Make sure the removal is accurate based on your understanding. Look for typos or grammar mistakes. Work with PM and PMM to ensure a consistent GitLab style and tone for messaging, based on other features and removals.
  • Review use of whitespace and bullet lists. Will the removal item be easily scannable when published? Consider adding line breaks or breaking content into bullets if you have more than a few sentences.
  • Make sure there aren't acronyms readers may not understand per https://about.gitlab.com/handbook/communication/#writing-style-guidelines.
• Links:
  • All links must be full URLs, as the removal YAML files are used in multiple projects. Do not use relative links. The generated doc is an exception to the relative link rule and currently uses absolute links only.
  • Make sure all links and anchors are correct. Do not link to the H1 (top) anchor on a docs page.
• Code. Make sure any included code is wrapped in code blocks.
• Capitalization. Make sure to capitalize feature names. Stay consistent with the Documentation Style Guidance on Capitalization.
• Blank spaces. Remove unnecessary spaces (end of line spaces, double spaces, extra blank lines, and lines with only spaces).

When the PM indicates it is ready for merge and all issues have been addressed, start the merge process.

Technical writer merge process

The removals doc's .md file must be updated before this MR is merged:

1. Check out the MR's branch (in the gitlab-org/gitlab project).
2. From the command line (in the branch), run bin/rake gitlab:docs:compile_removals. If you want to double check that it worked, you can run bin/rake gitlab:docs:check_removals to verify that the doc is up to date.
3. Commit the updated file and push the changes.
4. Set the MR to merge when the pipeline succeeds (or merge if the pipeline is already complete).

If you have trouble running the rake task, check the troubleshooting steps.

assigned to @dhershkovitch

	1 Message
	This merge request adds or changes documentation files. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge.

Documentation review

The following files require a review from a technical writer:

• doc/update/removals.md (Link to current live version)

The review does not need to block merging this merge request. See the:

• Metadata for the *.md files that you've changed. The first few lines of each *.md file identify the stage and group most closely associated with your docs change.
• The Technical Writer assigned for that stage and group.
• Documentation workflows for information on when to assign a merge request for review.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

Proper labels assigned to this merge request. Please ignore me.

@dhershkovitch - please see the following guidance and update this merge request.

	1 Error
	Please add typebug typefeature, or typemaintenance label to this merge request.

assigned to @marcel.amirault

added Technical Writing devopsverify grouppipeline authoring maintenancerefactor release post release post item release post itemremoval typemaintenance labels

added sectionops label

resolved all threads

changed milestone to %16.0

unassigned @marcel.amirault

requested review from @marcel.amirault

changed the description

@dhershkovitch Thanks, like the other MR I updated the description, added the labels, and so on. I have two small suggestions, but mainly we need to wait for @lma-git or @marknuzzo to verify !120050 (merged) is merged without problem and then please assign to me and I'll get this merged

removed review request for @marcel.amirault

resolved all threads

resolved all threads

added 1 commit

• 58c898a9 - Apply 2 suggestion(s) to 1 file(s)

Compare with previous version

mentioned in merge request !120050 (merged)

mentioned in issue #352957 (closed)

Setting label(s) Category:Pipeline Composition based on grouppipeline authoring.

added Category:Pipeline Composition label

assigned to @marcel.amirault

mentioned in issue #404533 (closed)

requested review from @marcel.amirault

unassigned @marcel.amirault

added docsfeature label

resolved all threads

marked this merge request as ready

added 689 commits

• 58c898a9...66452660 - 686 commits from branch master
• 7a57dadc - Add variable removal
• 852b3692 - Apply 2 suggestion(s) to 1 file(s)
• 5033871b - Regenerate removals doc

Compare with previous version

enabled an automatic merge when the pipeline for d761fa2c succeeds

added documentation label

merged

mentioned in commit 1a316f6e

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label

added workflowproduction label and removed workflowstaging label

added releasedcandidate label