Consider action for computing build name

[jzheaux]

A common need when working with artifactory is consistently determining the build name. Numerous projects use ${{ github.event.repository.name }}-${{MAJOR}}.${{MINOR}}.x. It may be nice to create an action that does this.

[artembilan]

This is how it looks so far in my case for Gradle:

    - name: Evaluate Build Name
      id: build-name
      shell: bash
      run: |
        echo Evaluate Build Name

        branchVersion=${{ github.ref_name }}

        if [ $branchVersion = 'main' ]; then
            snapshotVersion=$(cat gradle.properties | sed -n '/^version=/ { s/^version=//;p }')
            branchVersion=${snapshotVersion%.*}.x
        fi

        buildName=${{ github.event.repository.name }}-$branchVersion${{ inputs.releaseVersion != '' && '-release' || '' }}
        buildNumber=${{ github.run_number }}
        
        echo buildName=$buildName >> $GITHUB_OUTPUT
        echo buildNumber=$buildNumber >> $GITHUB_OUTPUT
        
        echo "::notice title=Artifactory Build Name & Number::$buildName/$buildNumber"

Note about that -release suffix we have agreed upon between teams some time ago when we started to migrate to GHA.

[jzheaux]

Thanks for the detailed write-up, @artembilan! Before implementing this, I wanted to do some research on the -release suffix convention you mentioned.

Here's what I found across several Spring projects:

Spring Framework (release.yml, build-and-deploy-snapshot.yml):

• Snapshot: spring-framework-{major}.{minor}.x
• Release: spring-framework-{version}

Spring Boot (release.yml, build-and-deploy-snapshot.yml):

• Snapshot: spring-boot-{major}.{minor}.x
• Release: spring-boot-{version}

Spring Security (deploy-artifacts.yml):

• Snapshot: spring-security-{major}.{minor}.x
• Security doesn't push releases to artifactory

Spring Pulsar (ci.yml):

• Snapshot: spring-pulsar-{major}.{minor}.x
• Pulsar doesn't push releases to artifactory

Spring Batch (continuous-integration.yml, artifactory-staging.yml):

• Snapshot: spring-batch-main
• Release: spring-batch-{version}

The only place I found the -release suffix is in spring-github-workflows (spring-artifactory-gradle-build/action.yml), which was added in 72d7c832ae.

You mentioned that the -release suffix was "agreed upon between teams some time ago when we started to migrate to GHA." Can you help me understand the context behind that? Based on the above, the major projects don't appear to use it, so I want to make sure we land on the right convention before baking it into a shared action.

[artembilan]

Great investigation, @jzheaux !

agreed upon between teams some time ago

I think we need call out @wilkinsona on that.
I don't remember the story about spring-boot-{version} pattern, but if that is what we should use, then I'm totally fine.
Let's just get 👍 from @wilkinsona and we are good to go!

Thanks again!

[wilkinsona]

I think we should hold fire on creating an action for this sort of thing until we've figured out the bigger picture. The examples above show that it's pretty straightforward to either hardcode it or create it directly in a workflow definition. Given this, I'm not sure that the logic is complex enough to warrant creating an action. An action would give us consistency but so too could whatever's maintaining and updating each project's workflow files.

[jzheaux]

@wilkinsona thanks for your thoughts; I agree there’s no rush to add an action for this.

I wouldn’t treat pending workflow generation as a strong reason to wait on its own. I’m very much in favor of that direction, but it’s still experimental, and I don’t assume every project will land there at the same time. In the meantime, small shared actions feel like practical stepping stones that will make workflow generation a simpler move.

Separately, the YAML for this is simple, sure, but calling an action can be similarly simple while keeping the naming and concatenation rules in one reviewed and tested place. I also favor an action over inlining since it encourages collaboration, adding a reasonable amount of friction against workflow drift.

Finally, I don’t plan to hold work here solely on the grounds that a future generator might prefer to inline this. I could be wrong about that long-term, but these actions aren’t GA yet, so the cost of trying that approach feels low either way.