Update composite for stacks-core releases

[wileyj]

Quick question to clarify the expected tag format:
Should the value passed here look like signer-3.0.0.0.1.0-rc1, or just 3.0.0.0.1.0-rc1?

Based on the releated README, it seems the prefixed version (signer-…) is what we should receive.
If that’s correct, we could simplify the detection logic entirely by checking whether the tag starts with "signer-" instead of inferring it indirectly from the character count.

Alternatively, since this is an important piece of behavior, we might want to expose an explicit input parameter (e.g., release_type: signer | node) so the caller clearly indicates what kind of release it is, rather than relying on implicit parsing.

Originally posted by @federico-stacks in #91 (comment)

todo

we could probably reduce the complexity of how these composites work. the calling workflow calls 1 one composite, which then calls the same workflow twice (for a non-signer release).

we could simplify this by calling a single composite from matrix, optionally passing as an input the type of build it is (for the artifact naming needed for the archive upload).

[wileyj]

additional notes from PR comment:

Should the value passed here look like signer-3.0.0.0.1.0-rc1, or just 3.0.0.0.1.0-rc1?

it could be either, depending on the type of release

Based on the releated README, it seems the prefixed version (signer-…) is what we should receive.

that's just an example usage, it would also be valid to use it like this:

name: Action
on: push
jobs:
  build:
    name: Job
    runs-on: ubuntu-latest
    steps:
      - name: Create Release
        id: create_release
        uses: stacks-network/actions/stacks-core/release/create-release@main
        with:
          tag: 3.0.0.0.1
          GH_TOKEN: ${{ inputs.GH_TOKEN }}

Alternatively, since this is an important piece of behavior, we might want to expose an explicit input parameter (e.g., release_type: signer | node) so the caller clearly indicates what kind of release it is, rather than relying on implicit parsing.

i did consider that, and it could be a future change to make. the calling workflow from stacks-core actually is calling this workflow: https://github.com/stacks-network/actions/blob/main/stacks-core/release/create-releases/action.yml

which is a "dumb" workflow that calls the workflow you've commented on. i think it could be simplified to do what you suggest. to accomplish the same with the current composites though, we'd have to pass along more inputs which i was trying not to do. since the artifacts we're using now are named slightly differently - this felt like the easiest way to know the type of release. in hindsight, maybe something like this would have been better?

echo ${{ inputs.tag }}| grep signer > /dev/null || false
if [ "$?" == "0" ]; then
  echo "release_type=stacks-signer" >> $GITHUB_OUTPUT
else
  echo "release_type=stacks-core" >> $GITHUB_OUTPUT
fi

i'm not 100% certain that would work for all scenarios and would need to re-test them.

ultimately, you're correct though - we could simplify this logic (and remove one of the composites most likely).
is that worth the effort in this PR is the question, or should it be addressed after?