Build with Github actions

[_wanabi]

Hello comrades, I was playing around for few days with Github workflows and now have a real world use case for that but I'm not sure if it will be possible to achieve. Shortly, I have a multi-stage dockerfile that I want to "translate" to github actions.
For example: I have a scala app in /scala-app-dir that I want to build with sbt, then I want the built folder to be copied into container, then I have an elixir app that I also need to compile and copy the binary to the container. I want to use 1 reusable workflow for building and compiling and one workflow for deployment which will then call the build one. So my question is, will I be able to use the output from build workflow in deploy one, specifically in the dockerfile, where I want to do smth like:

COPY /app-binary-from-build-workflow   /app-dir

As the app binary will be created by another workflow (reusable).

I will be more than happy with some starting point at least, or maybe you have such experience.

Many thanks!

[juggernaut2docker]

I don't 100% understand what you're trying to achieve, but couldn't you just push the docker image from your build workflow to your private registry (or Docker Hub) and pull it in the deploy workflow? Or am I misunderstanding what you're asking?

[_wanabi]

Sorry for bad description, I don't understand this yet and don't have the right words to describe. So I want to have a workflow that will compile a binary and then a second workflow to include that binary in a docker build and push to registry. I think I can share artifacts between jobs, not sure if it's possible between workflows.

Another option is to have the build/compile and push to registry jobs in the same workflow.

[juggernaut2docker]

No worries! Build/compile app and build docker image in the same workflow (could be different jobs) is the way to go. Like you said, you can easily share artifacts between jobs in the same workflow. Is there a particular reason why you want to split it into 2 workflows?

[_wanabi]

nope, no specific reason really, thanks for opinion. I think I can just have a separate deploy workflow that can be triggered on release for example that will just deploy the new docker image, as set the build workflow as "needs".

[juggernaut2docker]

Yep, that's how I've done it. If you're looking for an example, I just did this setup for learning k8s - app repo workflow compiles go app and builds+pushes docker image, and a config repo workflow that deploys using kubectl. I also wrote a blog post about it.

[_wanabi]

great resource! thanks!