Create separate docker image for stacks-signer

[wileyj]

          Looks good.

Alternatively, a different image would need to be published for the signer.

Originally posted by @friedger in #4682 (review)

[ldiego08]

@wileyj I'd like to assist with this issue. Based on this Dockerfile, would it be just adding the stacks-signer output? If so, what the CMD would be for that image (or the expected usage)?

[wileyj]

@wileyj I'd like to assist with this issue. Based on this Dockerfile, would it be just adding the stacks-signer output? If so, what the CMD would be for that image (or the expected usage)?

thanks for the offer, but it's a little more complicated than that - that dockerfile already contains the signer binary, since it's pulling a pre-built binary from the release page. the method that builds those archives is here: https://github.com/stacks-network/actions/blob/main/stacks-core/create-source-binary/build-scripts
i.e. https://github.com/stacks-network/actions/blob/main/stacks-core/create-source-binary/build-scripts/Dockerfile.linux-glibc-x64#L21

here's where it gets tricky though - right now, the current method is to build all the binaries, upload that archive to the releases page. the problem is that using this method means the signer can only be released when stacks-core is released (since the binary is only built as part of the release process).

one idea we've been thinking about is having a separate release process for the signer. the CI workflows will likely need to change quite a bit, but the overall idea is to release stacks-core normally like we do now (with the signer) using the existing 5 part versioning.
then, add a new ci workflow to release only the signer, which would assume a 6 part versioning (in between stacks-core releases).

it's possible we could re-use the dockerfile you linked, maybe add an ARG or something if we're only building the signer image? the same would need to be done for the stacks-network/actions repo (some kind of flag so we build the archive of only the signer, or everything in the case of stacks-core).

@BowTiedDevOps is looking into the ci workflow changes, but if you wanted to take a shot at the dockerfile changes, happy to consider any ideas you may have there.

[ldiego08]

@wileyj, thanks for your reply! I'm new to the repo, but overhauling the CI workflows to accurately reflect the released artifacts sounds like a better, long-term solution. I'll look into this further and get back to you.

[wileyj]

@wileyj, thanks for your reply! I'm new to the repo, but overhauling the CI workflows to accurately reflect the released artifacts sounds like a better, long-term solution. I'll look into this further and get back to you.

there's always room for help if you're inclined - i would look at the dockerfiles in the actions repo folder i linked in previous comment. i'm pretty sure we can re-use those to build release binaries for both the signer, and in the case of stacks-core - all the binaries.

offhand, i think setting some kind of build arg in the dockerfile should be enough. i.e.
https://github.com/stacks-network/actions/blob/main/stacks-core/create-source-binary/action.yml#L74

        build-args: |
          STACKS_NODE_VERSION=${{ inputs.tag || env.GITHUB_SHA_SHORT }}
          ...
          SIGNER_ONLY=true # set to true if only building the signer, blank if all binaries. this should be set as in input variable

and then in the dockefiles, i.e.

ENV SIGNER=${TARGET_CPU}
...
if [ $SIGNER ]; then
  BUILD_FLAG="--bins stacks-signer"
fi
...
&& cargo build --features monitoring_prom,slog_json --release --workspace --target ${TARGET} ${BUILD_FLAG}

total pseudo-code by the way, but that's the idea i was thinking of

[wileyj]

#4968