<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "bug" label. For the Community Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug For the Enterprise Edition issue tracker: - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary CI/CD stages with a `&` in the name get rendered as `&amp;`; the HTML is doubly escaped. ### Steps to reproduce Name a CI/CD stage with a `&`. E.g., this is an abbreviated version of the `.gitlab-ci.yml` my project used: ```yaml stages: - "Lint & Test" lint: stage: "Lint & Test" allow_failure: false image: name: ubuntu:xenial script: - 'echo "Hello, world."' tags: - docker-pull-always ``` ### Example Project [Example Project Demonstrating the Bug](https://gitlab.com/thanatos1/bug-test-double-escaped-stage-names/pipelines/34499691) ### What is the current *bug* behavior? (Note: We are self hosted, however, the bug appears to also be present on GitLab.com.) Here is a screenshot of what we see, when using something like the above:  ### What is the expected *correct* behavior? Just "Lint & Test" We also went with this unusual name b/c before that, we had used more "identifier" like names, such as `lint_and_test`; however, the same screen will capitalize the name, resulting in "Lint_and_test", which is IMO ugly. Note that the "pipelines" page listing all pipelines (`https://.../{group}/{project}/pipelines`) does not exhibit either behavior. (Neither doubly escaping nor randomly capitalizing the first letter.) That is, the pipelines listing page works perfectly! ### Relevant logs and/or screenshots N/A / Above. ### Output of checks (If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com) This bug happens on GitLab.com, but was discovered on a self-hosted installation of GitLab. #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes (If you can, link to the line of code that might be responsible for the problem)