anchor.diff:    <img src="/assets/images/blog/dotnet-core-gocd/value-stream-map.png" alt="Value Stream Map" />
   </figure>
   
  -Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The “pkg” folder name came from the artifacts configuration from the first pipeline.
  +Now we can setup a task that fetches the artifacts from the first pipeline and another task to deploy. Here is what setting up a fetch task would look like. The "pkg" folder name came from the artifacts configuration from the first pipeline.
   <figure>
     <img src="/assets/images/blog/dotnet-core-gocd/fetch_artifacts.png" alt="Fetch Artifacts" />
   </figure>
   
   Now if we trigger the first pipeline again and manually trigger the second one we can see the agent was able to fetch the build output from the first pipeline.
   
  -```
  -  21:31:26.919 [go] Start to execute task: .
  -  21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
  -  21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
  -  21:31:32.052 [go] Current job status: passed. ```
  -
  -  <figure>
  -    <img src="/assets/images/blog/dotnet-core-gocd/agent-pkg.png" alt="Agent Pkg" />
  -  </figure>
  +    21:31:26.919 [go] Start to execute task: .
  +    21:31:26.920 [go] Fetching artifact [pkg] from [hwPackagePipeline/8/defaultStage/1/defaultJob]
  +    21:31:32.017 [go] Saved artifact to [pipelines\hwDeployPipeline] after verifying the integrity of its contents.
  +    21:31:32.052 [go] Current job status: passed.
  +
  +<figure>
  +  <img src="/assets/images/blog/dotnet-core-gocd/agent-pkg.png" alt="Agent Pkg" />
  +</figure>
   
   ### Review
   
  -GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don’t need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.
  -
  -<style type="text/css">
  -.float-image {
  -  max-width: 25%;
  -}
  -
  -.float-image img {
  -  max-width: 100%;
  -}
  -
  -.float-image img.pad-right {
  -  padding-right: 10px;
  -}
  -
  -.float-image img.pad-left {
  -  padding-left: 10px;
  -}
  -
  -.float-article {
  -  max-width: 75%;
  -}
  -
  -.float-left {
  -  float: left;
  -}
  -
  -.float-right {
  -  float: right;
  -}
  -
  -.clear {
  -  clear: both;
  -}
  -
  -@media (max-width: 699px) {
  -  .float-left, .float-right {
  -    float: none;
  -  }
  -
  -  .float-image {
  -    max-width: 100%;
  -  }
  -
  -  .float-article {
  -    max-width: 100%;
  -  }
  -}
  -</style>
  +GoCD has a very good model and abstraction for how to build deployment pipelines. For example, when working on a task like packaging you don't need to worry about anything else. It leads you to using smaller focused scripts in the right places. Also, the concept of pipelines as a material give a powerful way to break up your deployment process. In my example I used another pipeline, setup with an initial task to wait for manual approval. Then after approval a fetch task runs which copies the artifacts from the build of the first pipeline, which then can be used for deployment.
  
positive.code: 
  From the pipeline view if you click on the green bar you can view the job console ouput. I confirmed the label was updated correctly during the package task.
  
  ```
  19:04:59.567 [go] Start to execute task:
  /c
  package.cmd %GO_PIPELINE_LABEL%
  .
  19:04:59.598
  19:04:59.598 C:\demo\GoCD\Agent\pipelines\hwPackagePipeline>IF [2] == [] GOTO error
  19:05:00.022 Project hwPackagePipeline (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
  19:05:00.072 Producing nuget package "hwPackagePipeline.1.0.0-2" for hwPackagePipeline
  19:05:00.118 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.nupkg
  19:05:00.118 Producing nuget package "hwPackagePipeline.1.0.0-2.symbols" for hwPackagePipeline
  19:05:00.122 hwPackagePipeline -> C:\demo\GoCD\Agent\pipelines\hwPackagePipeline\_build\hwPackagePipeline.1.0.0-2.symbols.nupkg
  19:05:00.184 [go] Current job status: passed.
  ```
  
  Now that the build, test, and packaging is done I can move on to creating a pipeline for acceptance tests and deployment with required approval. The second pipeline will use the first for it’s material. Before we can create the second pipeline we need to go into the first and setup the jobs build artifacts.
  
  **Note:** *Also by adding a test artifact GoCD will display the results in the tests tab. You can use Go with any XUnit style xml reports.*
  
  <figure>
    <img src="/assets/images/blog/dotnet-core-gocd/gocd_artifacts.png" alt="GoCD Artifacts" />
  </figure>
  
  Now via the admin tab and selecting pipelines, I can click on “Create a new pipeline within this group”. On step one I’ll name the new pipeline “hwDeployPipeline”.
  
  **Note:** *GoCD supports pipeline templates. Deployment pipelines would be a good use case for a template.*
  
  For step two the material will be “Pipeline” and the pipeline will be the stage we created earlier. GoCD has autocomplete text boxes. I didn’t have to type the stage name in the screenshot below.
  
  <figure>
    <img src="/assets/images/blog/dotnet-core-gocd/pipeline-as-material.png" alt="Pipeline as Material" />
  
negative.code: 
  ### Material Setup
  
  - First I'll setup a file based git server in `C:\demo\git_server`. I'm just doing this for simplicity. You could also use Github or another SCM server.
  
        mkdir hwapp
        cd hwapp
        git init --bare
  
  - Then I'll setup a share so the git repo can be used as a material and cloned into my development folder.
  
        \\lenovo-pc\git_server\hwapp
  
  - Then clone that into my development folder.
  
        cd development
        git clone \\lenovo-pc\git_server\hwapp
  
  - Now we will just setup the [hello world .NET Core](https://www.microsoft.com/net/core#windows) app.
  
        cd hwapp
        dotnet new
  
  - Then run it to make sure everything is working.
  
        dotnet restore
        dotnet run
  
  - Add a .gitignore file (with contents):
  
        bin/
        obj/
        project.lock.json
        _build
  
  - To keep things simple I won't use a build tool and just write a few small windows commands.
  
    - build.cmd file contents:
  
          git clean -xfd
          dotnet restore
          dotnet build
  
    - test.cmd file contents:
  
          dotnet test
  
    - package.cmd file contents:
  
          IF [%1] == [] GOTO error
          @Echo Off
          dotnet pack -o _build --version-suffix %1
          EXIT /B
          :error
          Echo version required.
  
  - Add some example unit tests using [Xunit.net](https://xunit.codeplex.com/):
  
    Here is my updated project json to allow me to run xunit tests.
  
          {
            "version": "1.0.0-*",
            "testRunner": "xunit",
            "buildOptions": {
  