anchor.diff:  For step two the material will be "Pipeline" and the stage 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" />
  +  <img src="/assets/images/blog/dotnet-core-gocd/pipeline-as-material.png" alt="GoCD Pipeline as Material" />
   </figure>
   
   In step three, I setup a manual stage and a task that represents acceptance tests were performed. If a step in your pipeline is not yet automated this could be a way to incrementally work towards automation.
   <figure>
  -  <img src="/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample.png" alt="Manual Acceptance Test Example" />
  +  <img src="/assets/images/blog/dotnet-core-gocd/manualAcceptanceTestExample.png" alt="GoCD Manual Acceptance Test Example" />
   </figure>
   
   Now I can save the new pipeline and unpause it. If we now go back to the main pipeline page and trigger the build we will see the first pipeline build and the second one will wait to be manually triggered. Once you click into the second pipeline and click on the purple arrow button it will run.
   
   The value stream will look like this after both pipelines complete. You can view value stream map for any build by clicking on the build label.
   <figure>
  -  <img src="/assets/images/blog/dotnet-core-gocd/value-stream-map.png" alt="Value Stream Map" />
  +  <img src="/assets/images/blog/dotnet-core-gocd/value-stream-map.png" alt="GoCD 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.
   <figure>
  -  <img src="/assets/images/blog/dotnet-core-gocd/fetch_artifacts.png" alt="Fetch Artifacts" />
  +  <img src="/assets/images/blog/dotnet-core-gocd/fetch_artifacts.png" alt="GoCD 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.
  
positive.code: author: Jason Rowe
  excerpt: "GoCD is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it. This post documents setting up a .NET core project in GoCD in a minimal way for demo purposes."
  title_tag_of_header: ".NET Core and GoCD | GoCD Blog"
  meta_description: "GoCD is a great way to learn the concepts and abstractions to help model your delivery pipeline and work towards improving it. This post documents setting up a .NET core project in GoCD in a minimal way for demo purposes."
  meta_keywords: "GoCD, continuous delivery, goforcd, open source, software, contribute to open source, agile continuous delivery, code contribution, Go, dotnet, .NET, .NET core, pipeline"
  summary_image: "/assets/images/blog/dotnet-core-gocd/dotnet_core_masthead.png"
  ---
  <% content_for :banner do %>
  
negative.code:     21:31:32.052 [go] Current job status: passed.
  
  <figure>
    <img src="/assets/images/blog/dotnet-core-gocd/agent-pkg.png" alt="GoCD Agent Pkg" />
  </figure>
  
  ### Review
  