More Japanese localization (circleci#3011)

Localizing following pages

building-docker-images.md
caching.md
examples.md
env-vars.md

Author: kimh

jekyll/_cci2/building-docker-images.md

@@ -215,7 +215,7 @@ Then, the sample CircleCI `.circleci/config.yml` snippets below populate and bac
       docker cp $CACHE_PATH/. $NAME:/backup
       docker-compose -f docker-compose.yml -f docker/circle-dockup.yml up --no-recreate $NAME
       docker rm -f $NAME
-      
+
 # Back up the same volume to circle cache
 - run:
     name: Backing up bundler cache from docker volumes
@@ -239,7 +239,8 @@ Thanks to ryansch for contributing this example.
 
 [Docker Layer Caching]({{ site.baseurl }}/2.0/docker-layer-caching/)
 
+[job-space]({{ site.baseurl }}/2.0/glossary/#job-space)
+
+[primary-container]({{ site.baseurl }}/2.0/glossary/#primary-container)
 
-[job-space]: {{ site.baseurl }}/2.0/glossary/#job-space
-[primary-container]: {{ site.baseurl }}/2.0/glossary/#primary-container
-[docker-layer-caching]: {{ site.baseurl }}/2.0/glossary/#docker-layer-caching
+[docker-layer-caching]({{ site.baseurl }}/2.0/glossary/#docker-layer-caching)

jekyll/_cci2/caching.md

@@ -7,12 +7,12 @@ categories: [optimization]
 order: 50
 ---
 
-Caching is one of the most effective ways to make jobs faster on CircleCI by reusing the data from expensive fetch operations from previous jobs. 
+Caching is one of the most effective ways to make jobs faster on CircleCI by reusing the data from expensive fetch operations from previous jobs.
 
 * TOC
 {:toc}
 
-After an initial job run, future instances of the job will run faster by not redoing work. 
+After an initial job run, future instances of the job will run faster by not redoing work.
 
 ![caching data flow]( {{ site.baseurl }}/assets/img/docs/Diagram-v3-Cache.png)
 
@@ -36,9 +36,9 @@ Caching keys are simple to configure. The following example updates a cache if i
 ## Introduction
 {:.no_toc}
 
-Automatic dependency caching is not available in CircleCI 2.0, so it is important to plan and implement your caching strategy to get the best performance. Manual configuration in 2.0 enables more advanced strategies and finer control. 
+Automatic dependency caching is not available in CircleCI 2.0, so it is important to plan and implement your caching strategy to get the best performance. Manual configuration in 2.0 enables more advanced strategies and finer control.
 
-This document describes the manual caching available, the costs and benefits of a chosen strategy, and tips for avoiding problems with caching. **Note:** The Docker images used for CircleCI 2.0 job runs are automatically cached on the server infrastructure where possible. 
+This document describes the manual caching available, the costs and benefits of a chosen strategy, and tips for avoiding problems with caching. **Note:** The Docker images used for CircleCI 2.0 job runs are automatically cached on the server infrastructure where possible.
 
 For information about enabling a premium feature to reuse the unchanged layers of your Docker image, see the [Enabling Docker Layer Caching]({{ site.baseurl }}/2.0/docker-layer-caching/) document.
 
@@ -49,13 +49,13 @@ A cache stores a hierarchy of files under a key. Use the cache to store data tha
 
 Caching is a balance between reliability (not using an out-of-date or inappropriate cache) and getting maximum performance (using a full cache for every build).
 
-In general it is safer to preserve reliability than to risk a corrupted build or to build using stale dependencies very quickly. So, the ideal is to balance performance gains while maintaining high reliability. 
+In general it is safer to preserve reliability than to risk a corrupted build or to build using stale dependencies very quickly. So, the ideal is to balance performance gains while maintaining high reliability.
 
-## Caching Libraries 
+## Caching Libraries
 
 The dependencies that are most important to cache during a job are the libraries on which your project depends. For example, cache the libraries that are installed with `pip` in Python or `npm` for Node.js. The various language dependency managers, for example `npm` or `pip`, each have their own paths where dependencies are installed. See our Language guides and demo projects for the specifics for your stack: <https://circleci.com/docs/2.0/demo-apps/>.
 
-Tools that are not explicitly required for your project are best stored on the Docker image. The Docker image(s) pre-built by CircleCI have tools preinstalled that are generic for building projects using the language the image is focused on. For example the `circleci/ruby:2.4.1` image has useful tools like git, openssh-client, and gzip preinstalled.  
+Tools that are not explicitly required for your project are best stored on the Docker image. The Docker image(s) pre-built by CircleCI have tools preinstalled that are generic for building projects using the language the image is focused on. For example the `circleci/ruby:2.4.1` image has useful tools like git, openssh-client, and gzip preinstalled.
 
 ## Source Caching
 
@@ -70,9 +70,9 @@ As in CircleCI 1.0, it is possible and oftentimes beneficial to cache your git r
             - source-v1-{{ .Branch }}-{{ .Revision }}
             - source-v1-{{ .Branch }}-
             - source-v1-
-            
+
       - checkout
-      
+
       - save_cache:
           key: source-v1-{{ .Branch }}-{{ .Revision }}
           paths:
@@ -97,13 +97,13 @@ Even with the narrowest `restore_cache` option ({% raw %}`source-v1-{{ .Branch }
 
 That said, it's worth comparing build times with and without source caching; `git clone` is often faster than `restore_cache`.
 
-**NOTE**: The built-in `checkout` command disables git's automatic garbage 
+**NOTE**: The built-in `checkout` command disables git's automatic garbage
 collection. You might choose to manually run `git gc` in a `run` step prior to
 running `save_cache` to reduce the size of the saved cache.
 
 ## Writing to the Cache in Workflows
 
-Jobs in one workflow can share caches.  Note that this makes it possibile to create race conditions in caching across different jobs in workflows.
+Jobs in one workflow can share caches.  Note that this makes it possible to create race conditions in caching across different jobs in workflows.
 
 Cache is immutable on write: once a cache is written for a particular key like `node-cache-master`, it cannot be written to again. Consider a workflow of 3 jobs, where Job3 depends on Job1 and Job2: {Job1, Job2} -> Job3.  They all read and write to the same cache key.
 
@@ -166,7 +166,7 @@ For example, you may want to clear the cache in the following scenarios by incre
 
 ## Basic Example of Dependency Caching
 
-The extra control and power in CircleCI 2.0 manual dependency caching requires that you be explicit about what you cache and how you cache it. See the [save cache section](https://circleci.com/docs/2.0/configuration-reference/#save_cache) of the Configuring CircleCI document for additional examples.
+The extra control and power in CircleCI 2.0 manual dependency caching requires that you be explicit about what you cache and how you cache it. See the [save cache section]({{ site.baseurl }}/2.0/configuration-reference/#save_cache) of the Configuring CircleCI document for additional examples.
 
 To save a cache of a file or directory, add the `save_cache` step to a job in your `.circleci/config.yml` file:
 
@@ -182,7 +182,7 @@ To save a cache of a file or directory, add the `save_cache` step to a job in yo
 The path for directories is relative to the `working_directory` of your job. You can specify an absolute path if you choose.
 
 **Note:**
-Unlike the special step [`persist_to_workspace`](https://circleci.com/docs/2.0/configuration-reference/#persist_to_workspace),
+Unlike the special step [`persist_to_workspace`]({{ site.baseurl }}/2.0/configuration-reference/#persist_to_workspace),
 neither `save_cache` nor `restore_cache` support globbing for the `paths` key.
 
 ## Using Keys and Templates

jekyll/_cci2/configuration-reference.md

@@ -259,7 +259,7 @@ jobs:
           aws_secret_access_key: $ECR_AWS_SECRET_ACCESS_KEY  # or project UI envar reference
 ```
 
-It is possible to reuse [declared commands]({{ site.baseurl }}/2.0/reusing-config/) in a job when using version 2.1. The following example invokes the `sayhello` command. 
+It is possible to reuse [declared commands]({{ site.baseurl }}/2.0/reusing-config/) in a job when using version 2.1. The following example invokes the `sayhello` command.
 
 
 ```
@@ -403,7 +403,7 @@ A job that was not executed due to configured rules will show up in the list of
 
 **Note:** You must [open a support ticket](https://support.circleci.com/hc/en-us/requests/new) to have a CircleCI Sales representative contact you about enabling this feature on your account for an additional fee.
 
-After this feature is added to your paid plan, it is possible to configure CPU and RAM resources for each job as described in the following table. If `resource_class` is not specified or an invalid class is specified, the default `resource_class: medium` will be used. The `resource_class` key is currently only available for use with the `docker` executor. 
+After this feature is added to your paid plan, it is possible to configure CPU and RAM resources for each job as described in the following table. If `resource_class` is not specified or an invalid class is specified, the default `resource_class: medium` will be used. The `resource_class` key is currently only available for use with the `docker` executor.
 
 Class       | vCPUs       | RAM
 ------------|-----------|------
@@ -414,7 +414,7 @@ large       | 4 | 8GB
 xlarge      | 8 | 16GB
 {: class="table table-striped"}
 
-Java, Erlang and any other languages that introspect the `/proc` directory for information about CPU count may require additional configuration to prevent them from slowing down when using the CircleCI 2.0 resource class feature. Programs with this issue may request 32 CPU cores and run slower than they would when requesting one core. Users of languages with this issue should pin their CPU count to their guaranteed CPU resources. 
+Java, Erlang and any other languages that introspect the `/proc` directory for information about CPU count may require additional configuration to prevent them from slowing down when using the CircleCI 2.0 resource class feature. Programs with this issue may request 32 CPU cores and run slower than they would when requesting one core. Users of languages with this issue should pin their CPU count to their guaranteed CPU resources.
 
 #### **`steps`**
 
@@ -647,13 +647,13 @@ workflows:
     jobs:
       - job_with_optional_custom_checkout:
           custom_checkout: \"any non-empty string is truthy\"
-      - job_with_optional_custom_checkout            
+      - job_with_optional_custom_checkout
 ```
 
 ##### **`checkout`**
 
 Special step used to check out source code to the configured `path` (defaults to the `working_directory`).
-The reason this is a special step is because it is more of a helper function designed to make checking out code easy for you. If you require doing git over HTTPS you should not use this step as it configures git to checkout over ssh. 
+The reason this is a special step is because it is more of a helper function designed to make checking out code easy for you. If you require doing git over HTTPS you should not use this step as it configures git to checkout over ssh.
 
 Key | Required | Type | Description
 ----|-----------|------|------------
@@ -720,7 +720,7 @@ Template | Description
 {% raw %}`{{ .Revision }}`{% endraw %} | The VCS revision currently being built.
 {% raw %}`{{ .CheckoutKey }}`{% endraw %} | The SSH key used to checkout the repo.
 {% raw %}`{{ .Environment.variableName }}`{% endraw %} | The environment variable `variableName` (supports any environment variable [exported by CircleCI](https://circleci.com/docs/2.0/env-vars/#circleci-environment-variable-descriptions) or added to a specific [Context](https://circleci.com/docs/2.0/contexts)—not any arbitrary environment variable).
-{% raw %}`{{ checksum "filename" }}`{% endraw %} | A base64 encoded SHA256 hash of the given filename's contents. This should be a file committed in your repo and may also be referenced as a path that is absolute or relative from the current working directory. Good candidates are dependency manifests, such as `package.json`, `pom.xml` or `project.clj`. It's important that this file does not change between `restore_cache` and `save_cache`, otherwise the cache will be saved under a cache key different than the one used at `restore_cache` time. 
+{% raw %}`{{ checksum "filename" }}`{% endraw %} | A base64 encoded SHA256 hash of the given filename's contents. This should be a file committed in your repo and may also be referenced as a path that is absolute or relative from the current working directory. Good candidates are dependency manifests, such as `package.json`, `pom.xml` or `project.clj`. It's important that this file does not change between `restore_cache` and `save_cache`, otherwise the cache will be saved under a cache key different than the one used at `restore_cache` time.
 {% raw %}`{{ epoch }}`{% endraw %} | The current time in seconds since the unix epoch.
 {% raw %}`{{ arch }}`{% endraw %} | The OS and CPU information.  Useful when caching compiled binaries that depend on OS and CPU architecture, for example, `darwin amd64` versus `linux i386/32-bit`.
 {: class="table table-striped"}
@@ -927,25 +927,25 @@ baz
       - build/*
 ```
 
-The `paths` list uses `Glob` from Go, and the pattern matches [filepath.Match](https://golang.org/pkg/path/filepath/#Match). 
-
-``` 
-pattern: 
-        { term } 
-term: 
-        '*' matches any sequence of non-Separator characters 
-        '?' matches any single non-Separator character 
-        '[' [ '^' ] { character-range } 
-        ']' character class (must be non-empty) 
-        c matches character c (c != '*', '?', '\\', '[') 
-        '\\' c matches character c 
-character-range: 
-        c matches character c (c != '\\', '-', ']') 
-        '\\' c matches character c 
-        lo '-' hi matches character c for lo <= c <= hi 
-``` 
-
-The Go documentation states that the pattern may describe hierarchical names such as `/usr/*/bin/ed` (assuming the Separator is '/'). **Note:** Everything must be relative to the work space root directory. 
+The `paths` list uses `Glob` from Go, and the pattern matches [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
+
+```
+pattern:
+        { term }
+term:
+        '*' matches any sequence of non-Separator characters
+        '?' matches any single non-Separator character
+        '[' [ '^' ] { character-range }
+        ']' character class (must be non-empty)
+        c matches character c (c != '*', '?', '\\', '[')
+        '\\' c matches character c
+character-range:
+        c matches character c (c != '\\', '-', ']')
+        '\\' c matches character c
+        lo '-' hi matches character c for lo <= c <= hi
+```
+
+The Go documentation states that the pattern may describe hierarchical names such as `/usr/*/bin/ed` (assuming the Separator is '/'). **Note:** Everything must be relative to the work space root directory.
 
 ##### **`attach_workspace`**
 
@@ -1021,7 +1021,7 @@ version | Y | String | Should currently be `2`
 A unique name for your workflow.
 
 #### **`triggers`**
-Specifies which triggers will cause this workflow to be executed. Default behavior is to trigger the workflow when pushing to a branch. 
+Specifies which triggers will cause this workflow to be executed. Default behavior is to trigger the workflow when pushing to a branch.
 
 Key | Required | Type | Description
 ----|-----------|------|------------
@@ -1055,7 +1055,7 @@ cron | Y | String | See the [crontab man page](http://pubs.opengroup.org/onlinep
 {: class="table table-striped"}
 
 ###### **`filters`**
-Filters can have the key `branches`. 
+Filters can have the key `branches`.
 
 Key | Required | Type | Description
 ----|-----------|------|------------
@@ -1275,20 +1275,20 @@ jobs:
       # Upload test results
       - store_test_results:
           path: /tmp/test-reports
-          
+
   deploy-stage:
     docker:
       - image: ubuntu:14.04
-    working_directory: /tmp/my-project  
+    working_directory: /tmp/my-project
     steps:
       - run:
           name: Deploy if tests pass and branch is Staging
-          command: ansible-playbook site.yml -i staging          
-          
+          command: ansible-playbook site.yml -i staging
+
   deploy-prod:
     docker:
       - image: ubuntu:14.04
-    working_directory: /tmp/my-project  
+    working_directory: /tmp/my-project
     steps:
       - run:
           name: Deploy if tests pass and branch is Master

jekyll/_cci2/examples.md

@@ -1,7 +1,7 @@
 ---
 layout: classic-docs
 title: "Testing Config Files Locally"
-description: "Example CircleCI 2.0 Configuration Files"
+description: "Testing Config Files Locally"
 ---
 
 <div class="alert alert-info" role="alert">
@@ -21,7 +21,7 @@ To add a script that tests your config file locally, complete the following step
   - Source for project
   - Project name
   - Branch from which to build
-5. Add those values into your shell script. 
+5. Add those values into your shell script.
 
 ```bash
 #!/usr/bin/env bash
@@ -38,4 +38,3 @@ Now you can run the shell script and debug your `config.yml` file without having
 ## See Also
 
 [Using the Local CircleCI CLI]({{ site.baseurl }}/2.0/local-cli/)
-