Merge branch 'fix/ci-config-hidden-key-validation' into 'master'

Do not enforce using a hash with hidden ci key

## What does this MR do?

This MR remove the validation rule that was to strict.

## Why was this MR needed?

Enforcing hidden CI job configuration to be a hash, narrows options of using YAML anchors, and was not backwards compatbile.

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Closes #21512

See merge request !6079

doc/ci/yaml/README.md

@@ -39,7 +39,7 @@ If you want a quick introduction to GitLab CI, follow our
     - [before_script and after_script](#before_script-and-after_script)
 - [Git Strategy](#git-strategy)
 - [Shallow cloning](#shallow-cloning)
-- [Hidden jobs](#hidden-jobs)
+- [Hidden keys](#hidden-keys)
 - [Special YAML features](#special-yaml-features)
     - [Anchors](#anchors)
 - [Validate the .gitlab-ci.yml](#validate-the-gitlab-ci-yml)
@@ -934,24 +934,27 @@ variables:
   GIT_DEPTH: "3"
 ```
 
-## Hidden jobs
+## Hidden keys
 
 >**Note:**
 Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
 
-Jobs that start with a dot (`.`) will be not processed by GitLab CI. You can
+Keys that start with a dot (`.`) will be not processed by GitLab CI. You can
 use this feature to ignore jobs, or use the
-[special YAML features](#special-yaml-features) and transform the hidden jobs
+[special YAML features](#special-yaml-features) and transform the hidden keys
 into templates.
 
-In the following example, `.job_name` will be ignored:
+In the following example, `.key_name` will be ignored:
 
 ```yaml
-.job_name:
+.key_name:
   script:
     - rake spec
 ```
 
+Hidden keys can be hashes like normal CI jobs, but you are also allowed to use
+different types of structures to leverage special YAML features.
+
 ## Special YAML features
 
 It's possible to use special YAML features like anchors (`&`), aliases (`*`)
@@ -967,7 +970,7 @@ Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
 
 YAML also has a handy feature called 'anchors', which let you easily duplicate
 content across your document. Anchors can be used to duplicate/inherit
-properties, and is a perfect example to be used with [hidden jobs](#hidden-jobs)
+properties, and is a perfect example to be used with [hidden keys](#hidden-keys)
 to provide templates for your jobs.
 
 The following example uses anchors and map merging. It will create two jobs,
@@ -975,7 +978,7 @@ The following example uses anchors and map merging. It will create two jobs,
 having their own custom `script` defined:
 
 ```yaml
-.job_template: &job_definition  # Hidden job that defines an anchor named 'job_definition'
+.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
   image: ruby:2.1
   services:
     - postgres
@@ -1081,7 +1084,7 @@ test:mysql:
     - ruby
 ```
 
-You can see that the hidden jobs are conveniently used as templates.
+You can see that the hidden keys are conveniently used as templates.
 
 ## Validate the .gitlab-ci.yml
 

lib/gitlab/ci/config/node/hidden_job.rb → lib/gitlab/ci/config/node/hidden.rb

@@ -5,11 +5,10 @@ module Gitlab
         ##
         # Entry that represents a hidden CI/CD job.
         #
-        class HiddenJob < Entry
+        class Hidden < Entry
           include Validatable
 
           validations do
-            validates :config, type: Hash
             validates :config, presence: true
           end
 

lib/gitlab/ci/config/node/jobs.rb

@@ -30,7 +30,7 @@ module Gitlab
 
           def compose!
             @config.each do |name, config|
-              node = hidden?(name) ? Node::HiddenJob : Node::Job
+              node = hidden?(name) ? Node::Hidden : Node::Job
 
               factory = Node::Factory.new(node)
                 .value(config || {})

spec/lib/gitlab/ci/config/node/hidden_job_spec.rb → spec/lib/gitlab/ci/config/node/hidden_spec.rb

 require 'spec_helper'
 
-describe Gitlab::Ci::Config::Node::HiddenJob do
+describe Gitlab::Ci::Config::Node::Hidden do
   let(:entry) { described_class.new(config) }
 
   describe 'validations' do
     context 'when entry config value is correct' do
-      let(:config) { { image: 'ruby:2.2' } }
+      let(:config) { [:some, :array] }
 
       describe '#value' do
         it 'returns key value' do
-          expect(entry.value).to eq(image: 'ruby:2.2')
+          expect(entry.value).to eq [:some, :array]
         end
       end
 
@@ -21,17 +21,6 @@ describe Gitlab::Ci::Config::Node::HiddenJob do
     end
 
     context 'when entry value is not correct' do
-      context 'incorrect config value type' do
-        let(:config) { ['incorrect'] }
-
-        describe '#errors' do
-          it 'saves errors' do
-            expect(entry.errors)
-              .to include 'hidden job config should be a hash'
-          end
-        end
-      end
-
       context 'when config is empty' do
         let(:config) { {} }
 

spec/lib/gitlab/ci/config/node/jobs_spec.rb

@@ -74,7 +74,7 @@ describe Gitlab::Ci::Config::Node::Jobs do
         expect(entry.descendants.first(2))
           .to all(be_an_instance_of(Gitlab::Ci::Config::Node::Job))
         expect(entry.descendants.last)
-          .to be_an_instance_of(Gitlab::Ci::Config::Node::HiddenJob)
+          .to be_an_instance_of(Gitlab::Ci::Config::Node::Hidden)
       end
     end