Merge branch 'master' into tjs/2948

Author: teesloane

.gitignore

@@ -7,7 +7,6 @@
 _site/
 jekyll/.jekyll-cache/
 jekyll/environments/
-jekyll/assets/js/dist/
 jekyll/_includes/app.html
 run-results/
 node_modules/

jekyll/_cci2/api-job-trigger.md

@@ -45,15 +45,16 @@ and refers to the name of your branch.
 For a complete reference of the API,
 see the [CircleCI API Documentation]({{ site.baseurl }}/api/v1-reference/).
 
-**Note:**
-It is possible to trigger [workflows]({{ site.baseurl }}/2.0/workflows/) with the CircleCI API, using a new endpoint, see the Trigger a Build by Project section of the [CircleCI API Projects Documentation]({{ site.baseurl }}/api/v1-reference/#new-project-build).
-
-Jobs triggered with the API may contain a `workflows` section.
-These workflows do **not** have to reference the job
-you trigger with the API.
-Jobs triggered with the API do **not** have access to environment variables
-created for [a CircleCI Context]({{ site.baseurl }}/2.0/contexts/).
-Instead, define these variables at the [Project level]({{ site.baseurl }}/2.0/env-vars/#setting-an-environment-variable-in-a-project).
+**Import Considerations When Triggering A Job Via The API**
+
+- Jobs triggered with the API may contain a `workflows` section
+- Your workflow does **not** have to reference the job you triggered with the API
+- Jobs that are triggered via the API do **not** have access to environment
+  variables created for [a CircleCI Context]({{ site.baseurl }}/2.0/contexts/)
+  - If you wish to use environment variables they have to be defined at the [Project level]({{ site.baseurl }}/2.0/env-vars/#setting-an-environment-variable-in-a-project)
+- It is currently not possible to trigger a single job if you are using CircleCI 2.1 and Workflows
+- It is possible to trigger [workflows]({{ site.baseurl }}/2.0/workflows/) with the CircleCI API, using the [Trigger a Build by Project]({{ site.baseurl}}/api/v1-reference/#new-project-build) endpoint
+
 
 ## Conditionally Running Jobs With the API
 

jekyll/_cci2/config-intro.md

@@ -50,9 +50,9 @@ The CircleCI config syntax is very straight forward.  The trickiest part is typi
 
 - Line 1: This indicates the version of the CircleCI platform you are using.  2.0 is the most recent version.
 - Line 2-3: The `jobs` level contains a collection of arbitrarily named children.  `build` is the first named child in the `jobs` collection.  In this case `build` is also the only job.
-- Line 4-5: The `steps` collection is an ordered list of `run` directives.  Each `run` directive is executed in the order in which it was declared.
-- Line 6: The `name` attribute provides useful organizational information when returning warnings, errors, and output.  The `name` should be meaningful to you as an action within your build process
-- Line 7-9: This is the magic.  The `command` attribute is a list of shell commands that represent the work you want done.  The initial pipe, `|`, indicates that there will be more than one line of shell commands.  Here line 8 will print out `Hello World` in your build shell and line 9 will print out `I’m the new delivery pipeline`
+- Line 6-7: The `steps` collection is an ordered list of `run` directives.  Each `run` directive is executed in the order in which it was declared.
+- Line 8: The `name` attribute provides useful organizational information when returning warnings, errors, and output.  The `name` should be meaningful to you as an action within your build process
+- Line 9-11: This is the magic.  The `command` attribute is a list of shell commands that represent the work you want done.  The initial pipe, `|`, indicates that there will be more than one line of shell commands.  Here line 10 will print out `Hello World!` in your build shell and line 11 will print out `This is the delivery pipeline`
 
 ## Part Two: Info and Preparing to Build
 That was nice but let’s get real.  Delivery graphs start with code.  In this example we will add a few lines that will get your code and then list it.  We will also do this in a second run.
@@ -131,11 +131,11 @@ The above two changes to the config significantly affect how you get work done.
 
 - Line 4: Here we see a comment in-line in yml.  Like any other unit of code, comments are a useful tool as config gets complicated.
 - Line 5-6: These lines indicate that docker image to use for the job.  Because you can have more than one job in your config (as we will see next) you can also run different parts of your config in different environments.  For example, you could perform a build job in a thin java container and then perform a test job using a container with browsers pre-installed. In this case, it uses  a [pre-built container from CircleCI]({{ site.baseurl }}/2.0/circleci-images/) that already has a browser and other useful tools built in.  
-- Line 9-12: These lines add a run step that returns the version of node available in the container. Try experimenting with different containers from CircleCI’s pre-built convenience images or even public containers from Docker hub.
+- Line 19-22: These lines add a run step that returns the version of node available in the container. Try experimenting with different containers from CircleCI’s pre-built convenience images or even public containers from Docker hub.
 
 ## Part Four: Approved to Start
 So far so good?  Let’s spend a moment on orchestration.  In this example, we will spend more time doing analysis than step-by-step modification.
-The CircleCI workflow model is based on the orchestration of predecessor jobs.  This is why the reserved word used for workflow definition is `requires.`  Jobs initiation is always defined in terms of the successful completion of prior jobs.  For example, a job vector such as [A, B, C] would be implemented with jobs B and C each requiring the job prior.  Job A would not have a requires block because it starts immediately. For example, job A starts immediately; B requires A; C requires B.
+The CircleCI workflow model is based on the orchestration of predecessor jobs.  This is why the reserved word used for workflow definition is `requires`.  Jobs initiation is always defined in terms of the successful completion of prior jobs.  For example, a job vector such as [A, B, C] would be implemented with jobs B and C each requiring the job prior.  Job A would not have a requires block because it starts immediately. For example, job A starts immediately; B requires A; C requires B.
 
 In the example below, an event triggering a build will cause `Hello-World` to start immediately.  The remainder of the jobs will wait.  When `Hello-World` completes, both `I-Have-Code` and `Run-With-Node` will start.  That is because both `I-Have-Code` and `Run-With-Node` require `Hello-World` to complete successfully before they can start.  Next, the approval job called `Hold-For-Approval` will become available when both `I-Have-Code` and `Run-With-Node` complete.  The `Hold-For-Approval` job is slightly different from the others.  It represents a manual intervention to allow the workflow to continue.  While the workflow is waiting for a user (through the CircleCI UI or API) to approve the job, all state is preserved based on the original triggering event.  CircleCI understands that Approval jobs may take hours or even days before completing - although we suggest hours over days. Once `Hold-For-Approval` completes through a manual intervention, the final job `Now-Complete` will run.
 
@@ -211,8 +211,8 @@ We now know how to create a workflow including a manual gate that you can use to
 - Line 12: The commands to get code are now in a job named `I-Have-Code`
 - Line 22: The Node example using the CircleCI pre-built image is now called `Run-With-Node`
 - Line 30: There is an additional job that operates similarly to `Hello-World` but it won’t run until the approval is complete - see line 57 in the workflow stanza.
-- Line 39-57: The config now has a workflow.  In the prior examples the CircleCI engine interpreted the config as having had a single-job workflow.  Here we are staying clear and spelling out the workflow we want to execute. This workflow demonstrates several useful capabilities. The `requires` statement represents a list of prior jobs that must complete successfully prior to the job in question starting.  In this example, both `I-Have-Code` and `Run-With-Node` must complete before `Hold-For-Approval` becomes active.  In addition, both `I-Have-Code` and `Run-With-Node` are dependent on `Hello-World` but not on each other. . This means that those two jobs will run in parallel as soon as `Hello-World` is complete.  This is useful if you have multiple jobs that are not directly dependent on one another and you want to improve wall-clock time.
-- Line 50-51: Most of the jobs are generic.  However, this job has a type.  In this case the type is `Approval` and requires a person through the CircleCI API or UI to take an action for the build to complete. Interleaving Approval jobs allows you to create gates that must be approved or managed prior to downstream jobs executing.
+- Line 39-57: The config now has a workflow.  In the prior examples the CircleCI engine interpreted the config as having had a single-job workflow.  Here we are staying clear and spelling out the workflow we want to execute. This workflow demonstrates several useful capabilities. The `requires` statement represents a list of prior jobs that must complete successfully prior to the job in question starting.  In this example, both `I-Have-Code` and `Run-With-Node` must complete before `Hold-For-Approval` becomes active.  In addition, both `I-Have-Code` and `Run-With-Node` are dependent on `Hello-World` but not on each other. This means that those two jobs will run in parallel as soon as `Hello-World` is complete.  This is useful if you have multiple jobs that are not directly dependent on one another and you want to improve wall-clock time.
+- Line 50-51: Most of the jobs are generic.  However, this job has a type.  In this case the type is `approval` and requires a person through the CircleCI API or UI to take an action for the build to complete. Interleaving approval jobs allows you to create gates that must be approved or managed prior to downstream jobs executing.
 
 
 The examples above were designed to provide a quick starter to the areas of functionality available through CircleCI config.  There remains a lot more.  Take a look at the rest of the documentation.  You will find that scheduled jobs, workspaces, artifacts, and more are all simple variations on the concepts you’ve learned here.  Now go forth and automate your CI/CD world!

jekyll/_cci2/contexts.md

@@ -65,7 +65,7 @@ Environment variables are used according to a specific precedence order, as foll
 2. Environment variables declared with the `environment` key for a `run` step.
 3. Environment variables set with the `environment` key for a job.
 4. Environment variables set with the `environment` key for a container.
-5. Context environment variables (assuming the user has access to the Context). See the [Contexts]( {{ site.baseurl }}/2.0/contexts/) documentation for instructions.
+5. Context environment variables (assuming the user has access to the Context).
 6. Project-level environment variables set on the Project Settings page.
 7. Special CircleCI environment variables defined in the [CircleCI Environment Variable Descriptions]({{ site.baseurl }}/2.0/env-vars/#built-in-environment-variables) section of this document.
 

jekyll/_cci2/creating-orbs.md

@@ -109,7 +109,7 @@ orbs:
   codecov: circleci/[email protected]
   my-orb:
     executors:
-      default:
+      specialthingsexecutor:
         docker:
           - image: circleci/ruby:1.4.2
     commands:
@@ -509,7 +509,10 @@ The animation shows snippets to give you an overview of the following steps for
 2. Running `circleci config process .circleci/config.yml` to process the config.
 3. Committing the change and checking that the build succeeds in the CircleCI app.
 4. Enabling orbs use under Settings > Security in the CircleCI app.
-5. Running `circleci namespace create ndintenfass` to create a namespace in which to publish to the [CircleCI Orb Registry](https://circleci.com/orbs/registry/).
+5. Running `circleci namespace create ndintenfass github ndintenfass_org` to create
+   a namespace in which to publish to the [CircleCI Orb
+   Registry](https://circleci.com/orbs/registry/), using Github as a VCS with
+   `ndintenfass` as the namespace and `ndintenfass_org` as the org-name. The org-name must exist already as an organization on CircleCI.
 6. Creating and committing an `orb.yml` file in a `.circleci/orbs/orb-utils` directory of the project repo with the content of a reusable executor and the `orb-doc-generation` job.
 7. Running `circleci orb create ndintenfass orb-utils` to create the orb in the namespace.
 8. Running `circleci orb publish dev .circleci/orbs/orb-utils/@orb.yml ndintenfass orb-utils test` to publish the dev:test orb.

jekyll/_cci2/databases.md

@@ -97,7 +97,7 @@ To use `pg_dump`, `pg_restore` and similar utilities requires some extra configu
 ```
      steps:
     # Add the Postgres 9.6 binaries to the path.
-       - run: echo '/usr/lib/postgresql/9.6/bin/:$PATH' >> $BASH_ENV
+       - run: echo 'export PATH=/usr/lib/postgresql/9.6/bin/:$PATH' >> $BASH_ENV
 ```
 
 ### Using Dockerize to Wait for Dependencies

jekyll/_cci2/server-ports.md

@@ -1,6 +1,6 @@
 ---
 layout: classic-docs
-title: "Using the Static Installation Scripts"
+title: "Server Ports"
 category: [administration]
 order: 1
 description: "Using CircleCI 2.0 static installation scripts."

jekyll/_cci2/using-orbs.md

@@ -104,7 +104,7 @@ jobs:
     executor:
       name: my-executor
     steps:
-      -run: echo outside the executor
+      - run: echo outside the executor
 ```
 
 

jekyll/_cci2/workflows.md

@@ -587,8 +587,6 @@ Go to Settings > Branches in GitHub and click the Edit button on the protected b
 
 - For demonstration apps configured with Workflows, see the [CircleCI Demo Workflows](https://github.com/CircleCI-Public/circleci-demo-workflows) on GitHub.
 
-- For troubleshooting a workflow with Waiting for Status in GitHub, see [Workflows Waiting for Status in GitHub]({{ site.baseurl }}/2.0/workflows-waiting-status).
-
 ## Video: Configure Multiple Jobs with Workflows
 {:.no_toc}