features:
# TOP FEATURE
  top:
    - name: Related Issues
      available_in: [starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/related_issues.html#related-issues'
      image_url: '/images/9_4/related_issues.png'
      description: |
        Whenever you share a link from one issue to another, GitLab shortens it and crosslinks it automatically.
        But when issues get longer and projects more complex, it becomes hard to manage links and quickly find
        related issues.

        To solve this problem, we're introducing Related issues. With Related issues, you can formally declare
        another issue as related. A link to the other issue, its status and name will be shown in each issue.

        Simply paste a link to the issue you want to link or search for it by typing `#` (as you were able to do already)
        to link it. In the future, we will introduce different types of relationships through this mechanism.

# PRIMARY FEATURES
  primary:
    - name: New Navigation
      available_in: [core, starter, premium]
      documentation_link: 'https://about.gitlab.com/blog/2017/07/17/redesigning-gitlabs-navigation/'
      documentation_text: "Learn more about the Navigation Redesign"
      image_url: '/images/9_4/new_ui.png'
      description: |
        To make it easier and faster to get around GitLab, we're working on
        updating our navigation. Because a new navigation can be a big disruption,
        we're releasing the first step as an opt-in configuration with GitLab 9.4.

        To enable the new navigation, click on your profile image in the top right corner and
        choose **Turn on new navigation**.

        We have made adjustments to the global top navigation and introduced contextual navigation in the left
        menu depending on what page you are currently viewing.
        The new UI is still a work in progress and will replace the existing navigation
        in the next few months, please see our [blog post](https://about.gitlab.com/blog/2017/07/17/redesigning-gitlabs-navigation/)
        about our process and what work still needs to be done.

        We'd love to hear [your feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917).

    - name: Web Application Monitoring
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/prometheus.html'
      documentation_text: "Read through the documentation on Web Application Monitoring"
      image_url: '/images/9_4/prometheus_monitoring.png'
      description: |
        As part of GitLab 9.0 we [launched system performance management](https://about.gitlab.com/blog/2017/03/22/gitlab-9-0-released/#environment-monitoring-ce-ees-eep)
        integrated with CI/CD deployments,
        [monitoring deployed applications](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8935)
        on Kubernetes by tracking CPU and Memory utilization. This was a great
        first step, and with GitLab 9.4 we are excited to launch Web Application Monitoring with support beyond Kubernetes.

        GitLab will now automatically detect key user experience indicators like throughput, error rate, and latency. Simply connect [Prometheus](https://prometheus.io) to a
        [supported load balancer or HTTP server](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/metrics.html),
        and it will identify and begin tracking these statistics.

        Delivering a great experience is everyone's responsibility, and GitLab is making this easier by closing the performance feedback loop in the tool developers use every day.

    - name: Group-level Secret Variables
      available_in: [core, starter, premium]
      documentation_link: 'http://docs.gitlab.com/ee/ci/variables/#secret-variables'
      image_url: '/images/9_4/group_variables.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/12729'
      description: |
        Secret variables are really useful when you need a safe place to store
        sensitive information. Until now, secret variables were stored at the project level.
        However, we know its common for different projects
        in the same group to share information on deployment or credentials for accessing external services.

        Group-level Secret Variables remove the need to duplicate variables
        from one project to the next: now you can enter these values once,
        and each project or subgroup in the group will access them automatically.
        It's also really simple to update these values. You just change them
        in one place and they'll be automatically modified for all of the projects.

    - name: Variables in Pipeline Schedules
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/pipelines/schedules.html#making-use-of-scheduled-pipeline-variables'
      image_url: '/images/9_4/schedule_variables.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32568'
      description: |
        In GitLab 9.2 we introduced [Pipeline Schedules](https://about.gitlab.com/blog/2017/05/22/gitlab-9-2-released/#pipeline-schedules)
        to automatically run pipelines at a specific interval of time, but most teams also want
        to specify different values for specific variables when running the schedule.

        In GitLab 9.4, we've added the ability to define variables when creating or modifying a pipeline schedule:
        these values will be added to all the other variables already defined.
        Using this feature, you can also redefine existing variables to have a different value only for that specific run,
        for example if you want to have a "daily" pipeline running some tests in a different way.

    - name: Environment-specific Secret Variables
      available_in: [premium]
      documentation_link: 'http://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-secret-variables'
      image_url: '/images/9_4/environment_variables.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2302'
      description: |
        Variables are often the right solution to define values that are then used during deployments to specific [environments](https://docs.gitlab.com/ee/ci/environments.html).
        Since different environments (e.g.: **staging** and **production**) may require different values for the same task,
        such as the app name, it is important to create a direct binding between some variables and the related environment.

        With GitLab 9.4, Environment-specific Variables are introduced to solve this issue, as developers can now define which environments
        will receive a variable, even using wildcards to include dynamic environments, like `review/*.
        It is now easy to deploy to different environments with a minimal effort!

    - name: GitLab Power-Up for Trello
      available_in: [core, starter, premium, ultimate]
      documentation_link: '/blog/2017/07/22/gitlab-trello-power-up-launch/'
      documentation_text: "Learn more about GitLab Power-Up for Trello"
      image_url: '/images/9_4/trello.png'
      reporter: jobv
      description: |
        Using both Trello and GitLab? Now you can make that experience even better with the new [GitLab Power-Up](https://docs.gitlab.com/ee/integration/trello_power_up.html)!
        In Trello, when viewing one of your boards, simply go to `Power-Ups` and scroll
        to the `GitLab` Power-Up. After setup, you will be able to attach merge requests
        to Trello cards.

        In Trello, you will need to configure your domain, such as `gitlab.com/api/v4` for GitLab.com,
        and add your personal token.

    - name: GitLab Slack App for GitLab.com
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html'
      image_url: '/images/9_4/enable_slack_app_gitlab_project.png'
      reporter: jobv
      description: |
        🚀 GitLab already integrated deeply with Slack (and [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/README.html#gitlab-mattermost), [Microsoft Teams](https://docs.gitlab.com/ee/user/project/integrations/microsoft_teams.html#microsoft-teams-service), and [HipChat](https://docs.gitlab.com/ee/user/project/integrations/hipchat.html#atlassian-hipchat)),
        but we didn't have an app in the Slack App Directory yet. Today we do 🎉! That means setting up
        Slack integration with your projects on GitLab.com is now much easier.

        You can set it up from your project settings in GitLab (**Settings > Integrations**). Soon
        it will be available from the Slack App directory as well. We're working together with
        Slack on making sure private instances will
        be able to use the same Slack App in the near future. Of course, private instances are able
        to integrate with Slack using the manual steps outlined in the
        [documentation](https://docs.gitlab.com/ee/user/project/integrations/slack_slash_commands.html).

# SECONDARY FEATURES
  secondary:
    - name: Improved Internationalization
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/development/i18n_guide.html'
      documentation_text: "Read through the Internationalization Contribution Guide"
      description: |
        We are accelerating our efforts with Internationalization. A big thank you
        to members of our community who are already contributing additional
        languages including Chinese, French, Japanese and Brazillian Portuguese.
        A huge thanks to [Huang Tao](https://gitlab.com/htve) for continuously
        contributing to the cause!

        In GitLab 9.4 we have added Internationalization support for the Commits page.

    - name: Unified Slack Interface
      available_in: [core, starter, premium]
      description: |
        With this release, we are unifying the issue information shown in Slack in response to a link being pasted,
        a [Slack slash command](https://docs.gitlab.com/ee/user/project/integrations/slack_slash_commands.html)
        being executed, or a [Slack notification](https://docs.gitlab.com/ee/user/project/integrations/slack.html).
        This provides a coherent experience regardless of how an issue is referenced in Slack.

    - name: Group Milestones
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/milestones/index.html#creating-a-group-milestone'
      description: |
        Milestones are fundamental to issue tracking. They are often used to designate a sprint (week 35),
        a release (9.4) or a category (Backlog) of issues and merge requests. Often milestones span
        multiple projects: you were already able to quickly create milestones in multiple projects
        at once in GitLab. To make this experience better, we've now added the ability to create _Group milestones_.

        Group milestones behave exactly like their counterpart _project milestones_, but are created in
        the group and from there available to all projects directly belonging to that project.

        To create a group milestone, visit your group and go to **Issues** and then **Milestones**.

    - name: PostgreSQL High Availability (Beta)
      available_in: [premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/high_availability/alpha_database.html'
      documentation_text: "Read through the documentation on PostgreSQL HA with Omnibus GitLab"
      description: |
        GitLab 9.4 arrives in Beta for deploying the bundled PostgreSQL
        server in a highly available manner, with a simple manual action to recover in the event
        a node goes down. This allows for a more robust deployment of GitLab, reducing the duration
        of an outage and potential for data loss. We are working to
        [automate the failover process](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2571) in a subsequent release.

    - name: Additional GitLab Service Metrics
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html'
      documentation_text: "Read through the documentation on monitoring GitLab"
      description: |
        With GitLab 9.4 we have added additional instrumentation to our Ruby on Rails code,
        providing insight into the HTTP requests, latency, and errors at the Rack middleware layer. We will continue to instrument additional areas of GitLab in subsequent releases.

    - name: Mini-Graph for Multi-Project Pipelines
      available_in: [premium]
      documentation_link: 'https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html#multi-project-pipeline-graphs'
      image_url: '/images/9_4/mini-graph.png'
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2602'
      description: |
        We recently introduced [Multi-Project Pipeline Graphs](https://about.gitlab.com/blog/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs) to easily
        follow dependencies between related projects.
        With GitLab 9.4 we extend this also to mini-graphs in the Merge Request widget, where you can now see pipelines for downstream projects with their current status.

    - name: GitLab Geo Improvements
      available_in: [premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/gitlab-geo/README.html'
      documentation_text: "Read through the documentation on GitLab Geo"
      reporter: stanhu
      description: |
        Notable changes:

        - GitLab Geo now supports PostgreSQL replication slots to prevent secondary Geo
        nodes from getting out of sync with the primary. See
        [the documentation](https://docs.gitlab.com/ee/gitlab-geo/database.html#step-3-initiate-the-replication-process)
        for more details on how to use it the primary.
        - We've increased the performance of replicating Git data by
        [adding more concurrent clone operations](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2351).
        - Geo now ships with an initial version of an event log cursor that allows the
        secondary track when it needs to update a Git repository. We'll be deprecating the use of
        Geo system hooks in the future.

    - name: Customizable Path for CI/CD Configuration
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.html#custom-ci-config-path'
      documentation_text: "Read through the documentation on GitLab CI/CD"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/32815'
      description: |
        GitLab defines CI/CD configuration in a YAML file named `.gitlab-ci.yml`
        that is located in the root of the repository.
        There are cases where you need to specify a different location for the
        definition of your pipelines, for example when you
        mirror a SVN repository and cannot have files in the root of the project.

        Starting with GitLab 9.4, you can now specify in **Settings > Pipelines** a custom
        path that will be used to read CI/CD configuration instead
        of the default `.gitlab-ci.yml`. A variable named `$CI_CONFIG_PATH` is available to
        jobs in order to access the current config location.

    - name: Object Storage for CI Artifacts
      available_in: [premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/job_artifacts.html#using-object-storage'
      documentation_text: "Read through the documentation on CI Artifacts"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ee/issues/2965'
      description: |
        As companies continue to embrace CI/CD across the organization, their
        artifact storage needs naturally increase as well. With GitLab 9.4 you can move
        existing [CI artifacts](https://docs.gitlab.com/ee/user/project/pipelines/job_artifacts.html)
        to [Amazon S3](https://aws.amazon.com/s3/), in order to free local space and enable
        artifacts to be saved cost effectively, reliably, and with nearly infinite scalability.
        For now this operation has to be run every time you want to move your local artifacts to S3,
        but in a future iteration it will be automatically done so all the new artifacts will be saved
        on object storage as soon as they're created, without the need of a manual migration.

    - name: New Cache Policy for CI/CD Configuration
      available_in: [core, starter, premium]
      documentation_link: 'http://docs.gitlab.com/ee/ci/yaml/#cache-policy'
      documentation_text: "Read through the documentation on GitLab CI/CD"
      reporter: bikebilly
      issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/33772'
      description: |
        The default behaviour of a caching job is to download the files at the start
        of execution, and to re-upload them at the end.
        This allows any changes made by the job to be persisted for future runs,
        and is known as the pull-push cache policy.

        The default behaviour of a caching step is to restore and archive dependencies of your jobs, allowing speed-up of subsequent runs.
        If any change is made to the cached content, it is pushed to the cache server by default, and this behavior is known as the pull-push cache policy.

        If you're not interested in updating the cached files for a specifig job, you can skip the upload step by setting `policy: pull` in the job specification.
        Alternatively, if you have a job that unconditionally recreates the cache without reference to its previous contents, you can use `policy: push`
        to save a lot of unnecessary load on the cache server. This feature requires GitLab Runner 9.4 or above.

    - name: Extended Docker Configuration for CI/CD
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#extended-docker-configuration-options'
      documentation_text: "Read through the documentation on extended Docker configuration options"
      reporter: bikebilly
      description: |
         In GitLab 9.4 we introduce new advanced configuration options for `.gitlab-ci.yml` that allow you more flexibility when defining Docker images
         that you want to use for your pipelines. These improvements require also GitLab Runner 9.4 or above.

         You can now specify a custom `entrypoint` for your Docker image, in order to override the default one: here is an example to set
         the entrypoint to `/bin/sh`, making the image suitable for GitLab CI jobs without further modifications:

             image:
               name: super/sql:experimental
               entrypoint: ["/bin/sh"]
         {: .language-yaml}

         You can also specify aliases for services to run multiple concurrent instances of the same Docker image, and specify commands directly in the configuration file.

             services:
             - name: super/sql:latest
               command: ["/usr/bin/super-sql", "run"]
               alias: super-sql-1
             - name: super/sql:latest
               alias: super-sql-2
          {: .language-yaml}

    - name: Improved Prometheus Monitoring of Kubernetes Deployments
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html#configuring-prometheus-to-monitor-kubernetes' #ok
      documentation_text: "Read through the documentation on monitoring Kubernetes"
      image_url:
      description: |
        Since the release of [GitLab 9.0](https://about.gitlab.com/blog/2017/03/22/gitlab-9-0-released/#environment-monitoring-ce-ees-eep), the Prometheus server bundled with Omnibus GitLab
        has supported monitoring Kubernetes nodes for CPU and Memory metrics. With the release
        of 9.4, the Prometheus server will also automatically monitor any
        [specifically annotated Pod metrics](https://prometheus.io/docs/operating/configuration/#<kubernetes_sd_config>)
        as well.

    - name: Security - Add LDAP SSL Certificate Verification
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/administration/auth/ldap.html#tls-server-authentication'
      documentation_text: "Read through the documentation on LDAP"
      description: |
        We added support for certificate verification for LDAP over SSL. This option will
        be disabled by default for backwards-compatibility until GitLab 10.0. Additionally,
        to aid in configuring a secure connection, you can now specify a CA certificate file
        and SSL version. Encryption method names `ssl` and `tls` have been deprecated in favor
        or `simple_tls` and `start_tls`, respectively.

    - name: Upcoming Omnibus Package Signing
      available_in: [core, starter, premium]
      gitlab_com: false
      description: |
        Starting with our 9.5 release on August 22nd, we will be signing all
        new packages going forward. Along with the 9.5.0 package, we will also be providing
        signed versions of the latest 9.4 and 9.3 releases.

        Package signing provides additional confidence that the `.deb` and `.rpm` files
        used to install GitLab have not been surreptitiously modified.

    - name: GitLab Mattermost 4.0
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/gitlab-mattermost/README.html'
      description: |
        GitLab 9.4 includes [Mattermost 4.0](https://about.mattermost.com/mattermost-4-0),
        [an open source Slack-alternative](https://about.mattermost.com/), with a new look,
        new mobile apps, new API and Italian language support.

        This version includes [security updates](http://about.mattermost.com/security-updates/)
        and upgrading is recommended.

    - name: GitLab Runner 9.4
      available_in: [core, starter, premium]
      documentation_link: 'https://docs.gitlab.com/runner'
      documentation_text: "Read through the documentation on GitLab Runner"
      image_url:
      description: |
        We're also releasing GitLab Runner 9.4 today!

        ##### Most interesting changes:

        * Improvements in Kubernetes volumes support ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/606) and [merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/625))
        * Support for cache policies in `.gitlab-ci.yml` file ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/621))
        * Extended Docker configuration in `.gitlab-ci.yml` file ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/596))
        * `--all` option added to `unregister` command ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/622))
        * Switch to Go 1.8 ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/620))

        List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/v9.4.0/CHANGELOG.md).

    - name: Omnibus Improvements
      available_in: [core, starter, premium]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      documentation_text: "Read through the documentation on Omnibus GitLab"
      description: |
        When using a container registry that is external to the Omnibus GitLab package,
        there is additional configuration required starting with the 9.4.0 release.

        Previously, only the path to the registry key used for communication between GitLab and the registry (`gitlab_rails['registry_key_path']`) was necessary.
        Now along with the path, it is also required to specify the content of the key by setting
        `registry['internal_key']` inside of `/etc/gitlab/gitlab.rb`. Documentation for utilizing an external registry will be available soon.

        Other changes:

        1. NGINX has been updated to the next stable version, 1.12.1
        1. openSUSE 42.2 is now officially supported


    - name: Performance Improvements
      available_in: [core, starter, premium]
      description: |
        We are continuing to make great strides improving
        the performance of GitLab in every release. We're committed to not only
        making individual instances of GitLab even faster,
        but also to greatly improving the performance of GitLab.com,
        an instance that has over 1 million users!

        In GitLab 9.4 we are shipping performance
        improvements for issues, projects, milestones, and a lot more!

        For a list of implementations, please check the merge requests for
        [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=9.4&label_name%5B%5D=performance)
        and
        [GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=9.4&label_name%5B%5D=performance).

# MVP
mvp:
  fullname: Matt Gresko
  gitlab: mgresko
  description: |
    Matt [added support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2020)
    for EC2 instance profile credentials when using AWS hosted elasticsearch clusters,
    while we could only use static IAM credentials to access them before.
    This is a complex contribution and a significant improvement to GitLab's
    integration with [elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html#enabling-elasticsearch),
    as it allows some aspects of our
    [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_global_search.html#advanced-global-search)
    functionality to be automatically configured when GitLab is run on AWS.

    Have we mentioned that Matt also worked on the
    [initial AWS implementation](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1305)?
    Yeah, he did! It's all amazing, thank you Matt! 🙌

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://www.pexels.com/photo/countryside-dawn-dusk-field-355521/'
  licence: CC0
  licence_url: 'https://www.pexels.com/photo-license/'

# CTA BUTTONS
cta:
  - title: "Join us for an upcoming event"
    link: '/events/'

# UPGRADE BAROMETER
barometer:
  description: |
    To upgrade to GitLab 9.4 from the latest 9.3 version,
    no downtime is required. To upgrade without downtime,
    please [consult the documentation on downtimeless upgrades](https://docs.gitlab.com/ee/update/README.html#upgrading-without-downtime).

    For this release we have migrations, post-deploy migrations,
    and to help with the larger migrations we have introduced background migrations.

    GitLab.com migrations took approximately 24 minutes and post-deploy
    migrations amounted for a total of around 54 minutes.
    Background migrations on the other hand are sidekiq jobs that will
    run synchronously, for this release these migrations took around two
    days to complete, no side effects were expected nor present, these
    target older pipeline builds so newer executed pipelines are not affected.

    GitLab Geo users, please consult the documentation on
    [upgrading Geo](https://docs.gitlab.com/ee/gitlab-geo/configuration.html#upgrading-geo).

# DEPRECATIONS
deprecations:
  - feature_name: openSUSE 42.1
    due: July 22nd, 2017.
    description: |
      As the openSUSE community has ended support for version 42.1,
      GitLab has ended support as well as [previously announced](https://about.gitlab.com/blog/2017/06/22/gitlab-9-3-released/#end-of-support-for-the-opensuse-42.1-omnibus-package).
      Please upgrade to OpenSUSE 42.2 which is officially supported.

  - feature_name: GitLab CI API v1, GitLab Runner 1.11.x
    due: September 22nd, 2017.
    description:
      In 9.0 we released a new version of GitLab Runner that is based on the new API v4 instead of the old CI API v1.
      We are still supporting the old version of the API in GitLab, so users that are still using
      GitLab Runners 1.11.x can take their time for the migration process.

      With GitLab 9.6, planned to be shipped on September 22nd, we are going to remove the old CI API from GitLab,
      making GitLab Runner 1.11.x unable to communicate with the system.

      If you are using old GitLab Runner (<9.0), or any tools that are using GitLab CI API v1, an upgrade will be required.
