<p>I use CircleCI to build a go binary that I want to run in a pod installed by Helm charts. I want to move the binary from CircleCI to the remote cluster so it's available when the pod starts. I know it's possible with volumes, like ConfigMap or Secrets but I'm not sure what the best way to do this.</p>

<p>I once made it work with a private docker registry and a kubernetes Secrets for the credentials of the registry but I don't like this option. I don't want to have to build and push a new docker image on every binary change.</p>

<pre><code>version: 2.1
jobs:
  build_and_deploy:
    docker:
      - image: circleci/golang:1.12.7
    steps:
      - checkout
      - run: go get -v -t -d ./...
      - run: go build cmd/main.go
      - run: ...
      - run: helm install

workflows:
  version: 2
  build:
    jobs:
      - build_and_deploy:
</code></pre>

<p>The expected result should be a new binary available on the cluster every time the job runs.</p>

<p>According to the best practices - the binary file should be applied during your build image execution - as mentioned by community above and <a href="https://developers.redhat.com/blog/2016/02/24/10-things-to-avoid-in-docker-containers/" rel="nofollow noreferrer">best developer practices</a>: </p>

<blockquote>
  <p>Don’t create images from running containers – In other terms, don’t use “docker commit” to create an image. This method to create an image is not reproducible  and should be completely avoided. Always use a Dockerfile or any other S2I (source-to-image) approach that is totally reproducible, and you can track changes to the Dockerfile if you store it in a source control repository (git).</p>
</blockquote>

<p>However, from another point of view you can consider:</p>

<p><strong>1</strong>. <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" rel="nofollow noreferrer">init contianers</a> to build your image directly on the cluster </p>

<p><strong>2</strong>. <a href="https://github.com/GoogleContainerTools/kaniko" rel="nofollow noreferrer">kaniko</a> with with external location of your build context (gcs bucket git repository) </p>

<p><strong>3</strong>. helm pre-install hook in order to use the above mentioned solutions</p>

<p><strong>4</strong>. finally other solutions like <a href="https://cloud.google.com/cloud-build/docs/quickstart-docker#preparing_source_files" rel="nofollow noreferrer">cloud build</a>  or <a href="https://cloud.google.com/cloud-build/docs/build-debug-locally" rel="nofollow noreferrer">cloud build locally</a>  </p>

<p>Please refer also to "<a href="https://itnext.io/what-i-learned-switching-from-circleci-to-google-cloud-build-b4405de2be38" rel="nofollow noreferrer">Switching from CircleCI to Google Cloud Build</a>". 
As described in the article above you can use <a href="https://keel.sh/docs/#helm-example" rel="nofollow noreferrer">keel</a>  to automatically update your deployments when the image in the docker repository is updated.</p>

<p>Please let me know if it helps.</p>
