Automatic merge of gitlab-org/gitlab master

doc/user/project/pages/index.md

@@ -7,14 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Pages **(FREE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80) in GitLab Enterprise Edition 8.3.
-> - Custom CNAMEs with TLS support were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173) in GitLab Enterprise Edition 8.5.
-> - [Ported](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14605) to GitLab Community Edition in GitLab 8.17.
-> - Support for subgroup project's websites was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30548) in GitLab 11.8.
-> - Bundled project templates were [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47857) in GitLab 11.8.
-
-With GitLab Pages, you can publish static websites
-directly from a repository in GitLab.
+With GitLab Pages, you can publish static websites directly from a repository
+in GitLab.
 
 <div class="row">
 <div class="col-md-9">
@@ -32,11 +26,11 @@ directly from a repository in GitLab.
 <div class="col-md-3"><img src="img/ssgs_pages.png" alt="Examples of SSGs supported by Pages" class="middle display-block"></div>
 </div>
 
-To publish a website with Pages, you can use any SSG,
-like Gatsby, Jekyll, Hugo, Middleman, Harp, Hexo, and Brunch, just to name a few. You can also
+To publish a website with Pages, you can use any static site generator,
+like Gatsby, Jekyll, Hugo, Middleman, Harp, Hexo, or Brunch. You can also
 publish any website written directly in plain HTML, CSS, and JavaScript.
 
-Pages does **not** support dynamic server-side processing, for instance, as `.php` and `.asp` requires.
+Pages does not support dynamic server-side processing, for instance, as `.php` and `.asp` requires.
 Learn more about
 [static websites compared to dynamic websites](https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/).
 
@@ -45,18 +39,18 @@ Learn more about
 To create a GitLab Pages website:
 
 | Document | Description |
-| -------- | ----------- |
-| [Create a `.gitlab-ci.yml` file from scratch](getting_started/pages_from_scratch.md)    | Add a Pages site to an existing project. Learn how to create and configure your own CI file. |
+|----------|-------------|
+| [Create a `.gitlab-ci.yml` file from scratch](getting_started/pages_from_scratch.md) | Add a Pages site to an existing project. Learn how to create and configure your own CI file. |
 | [Use a `.gitlab-ci.yml` template](getting_started/pages_ci_cd_template.md) | Add a Pages site to an existing project. Use a pre-populated CI template file. |
-| [Fork a sample project](getting_started/pages_forked_sample_project.md)               | Create a new project with Pages already configured by forking a sample project. |
-| [Use a project template](getting_started/pages_new_project_template.md)       | Create a new project with Pages already configured by using a template. |
+| [Fork a sample project](getting_started/pages_forked_sample_project.md) | Create a new project with Pages already configured by forking a sample project. |
+| [Use a project template](getting_started/pages_new_project_template.md) | Create a new project with Pages already configured by using a template. |
 
 To update a GitLab Pages website:
 
 | Document | Description |
-| -------- | ----------- |
+|----------|-------------|
 | [GitLab Pages domain names, URLs, and base URLs](getting_started_part_one.md) | Learn about GitLab Pages default domains. |
-| [Explore GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI/CD configuration options, Access Control, custom 404 pages, limitations, FAQ. |
+| [Explore GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI/CD configuration options, Access Control, custom 404 pages, limitations, and FAQ. |
 | [Custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) | Custom domains and subdomains, DNS records, and SSL/TLS certificates. |
 | [Let's Encrypt integration](custom_domains_ssl_tls_certification/lets_encrypt_integration.md) | Secure your Pages sites with Let's Encrypt certificates, which are automatically obtained and renewed by GitLab. |
 | [Redirects](redirects.md) | Set up HTTP redirects to forward one page to another. |
@@ -64,7 +58,7 @@ To update a GitLab Pages website:
 Learn more and see examples:
 
 | Document | Description |
-| -------- | ----------- |
+|----------|-------------|
 | [Static vs dynamic websites](https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/) | Static versus dynamic site overview. |
 | [Modern static site generators](https://about.gitlab.com/blog/2016/06/10/ssg-overview-gitlab-pages-part-2/) | SSG overview. |
 | [Build any SSG site with GitLab Pages](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/) | Use SSGs for GitLab Pages. |
@@ -74,7 +68,7 @@ Learn more and see examples:
 To use GitLab Pages, you must create a project in GitLab to upload your website's
 files to. These projects can be either public, internal, or private.
 
-GitLab always deploys your website from a very specific folder called `public` in your
+GitLab always deploys your website from a specific folder called `public` in your
 repository. When you create a new project in GitLab, a [repository](../repository/index.md)
 becomes available automatically.
 
@@ -95,24 +89,21 @@ The following diagrams show the workflows you might follow to get started with P
 
 ## Access to your Pages site
 
-If you're using GitLab Pages default domain (`.gitlab.io`),
-your website is automatically secure and available under
-HTTPS. If you're using your own custom domain, you can
-optionally secure it with SSL/TLS certificates.
+If you're using GitLab Pages default domain (`.gitlab.io`), your website is
+automatically secure and available under HTTPS. If you're using your own custom
+domain, you can optionally secure it with SSL/TLS certificates.
 
 If you're using GitLab.com, your website is publicly available to the internet.
 To restrict access to your website, enable [GitLab Pages Access Control](pages_access_control.md).
 
-If you're using a self-managed instance (Free, Premium, or Ultimate),
-your websites are published on your own server, according to the
-[Pages settings](../../../administration/pages/index.md) chosen by your sysadmin,
-who can make them public or internal.
+If you're using a self-managed instance, your websites are published on your
+own server, according to the [Pages settings](../../../administration/pages/index.md)
+chosen by your sysadmin, who can make them public or internal.
 
 ## Pages examples
 
-There are some great examples of GitLab Pages websites built for
-specific reasons. These examples can teach you advanced techniques
-to use and adapt to your own needs:
+These GitLab Pages website examples can teach you advanced techniques to use
+and adapt for your own needs:
 
 - [Posting to your GitLab Pages blog from iOS](https://about.gitlab.com/blog/2016/08/19/posting-to-your-gitlab-pages-blog-from-ios/).
 - [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/).
@@ -122,27 +113,27 @@ to use and adapt to your own needs:
 
 ## Administer GitLab Pages for self-managed instances
 
-If you are running a self-managed instance of GitLab (GitLab Community Edition and Enterprise Editions),
+If you are running a self-managed instance of GitLab,
 [follow the administration steps](../../../administration/pages/index.md) to configure Pages.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=dD8c7WNcc6s) about how to get started with GitLab Pages administration.
 
 ## Security for GitLab Pages
 
-If your username is `foo`, your GitLab Pages website is located at `foo.gitlab.io`.
-GitLab allows usernames to contain a `.`, so a user named `bar.foo` could create
-a GitLab Pages website `bar.foo.gitlab.io` that effectively is a subdomain of your
-`foo.gitlab.io` website. Be careful if you use JavaScript to set cookies for your website.
+If your username is `example`, your GitLab Pages website is located at `example.gitlab.io`.
+GitLab allows usernames to contain a `.`, so a user named `bar.example` could create
+a GitLab Pages website `bar.example.gitlab.io` that effectively is a subdomain of your
+`example.gitlab.io` website. Be careful if you use JavaScript to set cookies for your website.
 The safe way to manually set cookies with JavaScript is to not specify the `domain` at all:
 
 ```javascript
-// Safe: This cookie is only visible to foo.gitlab.io
+// Safe: This cookie is only visible to example.gitlab.io
 document.cookie = "key=value";
 
-// Unsafe: This cookie is visible to foo.gitlab.io and its subdomains,
+// Unsafe: This cookie is visible to example.gitlab.io and its subdomains,
 // regardless of the presence of the leading dot.
-document.cookie = "key=value;domain=.foo.gitlab.io";
-document.cookie = "key=value;domain=foo.gitlab.io";
+document.cookie = "key=value;domain=.example.gitlab.io";
+document.cookie = "key=value;domain=example.gitlab.io";
 ```
 
 This issue doesn't affect users with a custom domain, or users who don't set any

ee/app/models/dast_site.rb

@@ -11,8 +11,14 @@ class DastSite < ApplicationRecord
   validates :project_id, presence: true
   validate :dast_site_validation_project_id_fk
 
+  after_destroy :cleanup_dast_site_token
+
   private
 
+  def cleanup_dast_site_token
+    DastSiteToken.where(project_id: project.id, url: url).delete_all
+  end
+
   def dast_site_validation_project_id_fk
     return unless dast_site_validation_id
 

ee/spec/models/dast_site_spec.rb

@@ -44,4 +44,16 @@ RSpec.describe DastSite, type: :model do
       end
     end
   end
+
+  describe 'callbacks' do
+    context 'when there is a related site token' do
+      let_it_be(:dast_site) { create(:dast_site, project: project) }
+      let_it_be(:dast_site_token) { create(:dast_site_token, project: dast_site.project, url: dast_site.url) }
+      let_it_be(:dast_site_validations) { create_list(:dast_site_validation, 5, dast_site_token: dast_site_token) }
+
+      it 'ensures it and associated site validations cleaned up on destroy' do
+        expect { dast_site.destroy! }.to change { DastSiteToken.count }.from(1).to(0).and change { DastSiteValidation.count }.from(5).to(0)
+      end
+    end
+  end
 end