Variables to build release name?

[thebrightspark]

Hey, I'm just setting this up for one of my projects for the first time. However the docs in your README suggest that the name argument should be hardcoded...

Is there not any way I can have the name created using version numbers that the action should already know?

For example, what I want to achieve is something like:

- name: Publish
  uses: Kir-Antipov/mc-publish@v3.3
  with:
    # ... other setup here ...
    name: [${{ loader }} ${{ mcVersion }}] ${{ modVersion }}

That would aim to produce something like:
[Fabric 1.19.4] 1.0.0

My mod is using a multi-loader setup, so it supports both Fabric and Forge, hence the suggested loader variable there too. Although thinking about it more, this might be more appropriate using a matrix so that I can supply the correct files too, since they'll be in different locations per loader.

Aim here is preventing any need to edit the CI pipeline constantly, as this should not be necessary.

[Kir-Antipov]

However the docs in your README suggest that the name argument should be hardcoded...

Well, it doesn't really. It merely illustrates that this is a string input. The method you employ to generate and/or provide the required string is entirely up to you.

Is there not any way I can have the name created using version numbers that the action should already know?

Currently, there's no inherent mechanism to accomplish this (provided you're only using mc-publish and mc-publish only, although you can still achieve the desired outcome with a few extra automated steps in your workflow).

Furthermore, someone has already proposed employing home-brewed string interpolation for such scenarios. I'm genuinely contemplating this, but it's not a high priority right now. I need to finalize a wiki for this project, implement comprehensive support for modpacks and plugins (currently, mc-publish can publish them, but it cannot extract data from their metadata files), and provide support for additional platforms heavily requested by plugin developers.

That being said, the format would differ slightly from your proposal - I can't use ${{ var }} because it will conflict with GitHub's expression syntax; and I should avoid ${ var } to prevent issues with the JavaScript environment on my end and for the users that attempt to automatically provide these patterns. So, it might turn into anything from %{ var } to $mc{{ var }}.

Although thinking about it more, this might be more appropriate using a matrix so that I can supply the correct files too, since they'll be in different locations per loader.

This is precisely what I suggest for such scenarios, and this is the reason I'm not in hurry to incorporate custom string interpolation logic into my code - the scenario you describe can be fully automated already, it's just not as convenient, as if a feature like that would be built-in into mc-publish. You can find a similar example to your situation in #29. Let me know if you need anything beyond that.

I'll keep this issue open, as I'm truly interested in integrating the requested feature, although not right-right now.

[thebrightspark]

provided you're only using mc-publish and mc-publish only

Yeah basically I am! I'm not much experienced with GH Actions, and I believe something that keeps the CI file in sync with elsewhere in the project is really an anti-pattern - it's really a workaround.

the format would differ slightly from your proposal

Understandable, and honestly from my POV it doesn't matter what the format is as long as it works 😉

Anyways, I'll share what I've thrown together below for my project. I've used $mc{ <propHere> } for now as an example of how I intend to use the proposed feature. For the context, it's intended to be used with my Async Locator mod.

.publish-example-ci.yml

name: Gradle Release Artifact

on:
  release:
    types: [ created ]

permissions:
  contents: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
          server-id: github # Value of the distributionManagement/repository/id field of the pom.xml
          settings-path: ${{ github.workspace }} # location for the settings.xml file

      - name: Build Fabric
        uses: gradle/gradle-build-action@v2
        with:
          gradle-version: wrapper
          arguments: Fabric:build

      - name: Build Forge
        uses: gradle/gradle-build-action@v2
        with:
          gradle-version: wrapper
          arguments: Forge:build

      - uses: actions/upload-artifact@v3
        with:
          name: builds
          if-no-files-found: error
          path: |
            Fabric/build/libs/*.jar
            Forge/build/libs/*.jar

  publish:
    runs-on: ubuntu-latest
    needs:
      - build
    strategy:
      matrix:
        mod-loader: [Fabric, Forge]
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: builds

      - name: Publish Fabric
        uses: Kir-Antipov/mc-publish@v3.3
        with:
          modrinth-id: rkN8aqci
          modrinth-token: ${{ secrets.MODRINTH_TOKEN }}
          curseforge-id: 625069
          curseforge-token: ${{ secrets.CURSEFORGE_TOKEN }}
          name: [${{ matrix.mod-loader }} $mc{ mcVersion }] $mc{ modVersion }
          changelog-file: CHANGELOG.md
          java: 17
          files: |
            ${{ matrix.mod-loader }}/build/libs/!(*-@(dev|sources|javadoc)).jar
            ${{ matrix.mod-loader }}/build/libs/*-@(dev|sources|javadocs).jar

Edit:
Just to add my motivation for requesting this: I've for years been uploading mods manually to CF, but right now this mod is the only one I currently maintain, and I upload to both CF and Modrinth. Building and uploading 2 files to 2 different sites is "fine", however since my mod can be used as a library too, I'm interested in also uploading the sources and javadocs JARs... and suddenly that's 6 files and getting a bit of a pain. So I thought I'd invest time into looking into your action to help automate this for me 😄

[Kir-Antipov]

I'm not much experienced with GH Actions

And yet you use permissions, the latest versions of the actions, and multiple jobs in the same workflow, while correctly linking them via needs. You did a pretty good job here, no need to underestimate your skills :)

I believe something that keeps the CI file in sync with elsewhere in the project is really an anti-pattern - it's really a workaround.

Could you clarify your point here, please? GitHub Actions are intrinsically linked with the activities in your repository and its state. If you're referencing automatic alterations of workflow files, that's not what I was advocating for. I was suggesting finding a way to automate your objective inside the workflow itself, since there are no string interpolation capabilities in mc-publish (yet).

Just to add my motivation for requesting this: I've for years been uploading mods manually to CF, but right now this mod is the only one I currently maintain, and I upload to both CF and Modrinth. Building and uploading 2 files to 2 different sites is "fine", however since my mod can be used as a library too, I'm interested in also uploading the sources and javadocs JARs... and suddenly that's 6 files and getting a bit of a pain. So I thought I'd invest time into looking into your action to help automate this for me 😄

This is exactly why I built this action :) Maintaining even a single project across multiple platforms can be daunting, let alone when dealing with several ones!

Anyways, I'll share what I've thrown together below for my project.

I appreciate your efforts. Now let's actually make your configuration work, shall we? So, here are the changes I propose:

1. It would be more efficient to amalgamate the jobs into a single one. My perspective is that jobs should only be separated if they can be executed concurrently. In instances where the outputs of one step are needed in another, it's better to keep everything centralized. The exact rules of upload-artifact and download-artifact can be somewhat tricky and counterintuitive, hence it's advisable to avoid them if possible.

2. Next, we need to set up $mc{ mcVersion } and $mc{ modVersion } for you. I noticed that you include the necessary information in your tag names (e.g., "1.20-1.3.0"). We can leverage this to achieve your goals.

So, here's an enhanced version of your configuration:

name: Gradle Release Artifact

on:
  release:
    types: [created]

permissions:
  contents: write

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        mod-loader: [Fabric, Forge]
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: 17
          distribution: temurin
          server-id: github # Value of the distributionManagement/repository/id field of the pom.xml
          settings-path: ${{ github.workspace }} # location for the settings.xml file

      - name: Extract versions from tag name
        id: versions
        run: |
          readarray -td "-" VERSIONS <<< "${GITHUB_REF#refs/tags/}-"
          echo "minecraft-version=${VERSIONS[0]}" >> "${GITHUB_OUTPUT}"
          echo "mod-version=${VERSIONS[1]}" >> "${GITHUB_OUTPUT}"

      - name: Build ${{ matrix.mod-loader }}
        uses: gradle/gradle-build-action@v2
        with:
          gradle-version: wrapper
          arguments: ${{ matrix.mod-loader }}:build

      - name: Publish ${{ matrix.mod-loader }}
        uses: Kir-Antipov/mc-publish@v3.3
        with:
          modrinth-id: rkN8aqci
          modrinth-token: ${{ secrets.MODRINTH_TOKEN }}
          curseforge-id: 625069
          curseforge-token: ${{ secrets.CURSEFORGE_TOKEN }}
          name: [${{ matrix.mod-loader }} ${{ steps.versions.outputs.minecraft-version }}] ${{ steps.versions.outputs.mod-version }}
          changelog-file: CHANGELOG.md
          java: 17
          files: |
            ${{ matrix.mod-loader }}/build/libs/!(*-@(dev|sources|javadoc)).jar
            ${{ matrix.mod-loader }}/build/libs/*-@(dev|sources|javadocs).jar

Let me know if it does the job for you!

[thebrightspark]

You did a pretty good job here, no need to underestimate your skills :)

It's amazing how much I convinced you just by me writing this after reading the CI docs haha 😉

Could you clarify your point here, please? GitHub Actions are intrinsically linked with the activities in your repository and its state. If you're referencing automatic alterations of workflow files, that's not what I was advocating for.

Perhaps I've been thinking about this the wrong way? I've come from using GitLab's CI a lot for my job, so I've quite used to being able to just simply write scripts for jobs rather than relying on actions for all their logic 😅
And thinking more about it, usually you'd actually have the version determined by the CI pipeline, probably using some kind of Semantic versioning/release build plugin. Although I'm not sure how that'd be quite possible here - however, since this action serves the purpose of the releasing, how can you automate the versioning?

Anyways, I've read ahead and seen you've solved this haha.

It would be more efficient to amalgamate the jobs into a single one. My perspective is that jobs should only be separated if they can be executed concurrently.

That's fair, as you say it's pretty pointless here. Again, I've been used to how simple it is with GitLab and usually we separate jobs into separate distinct tasks. But yeah again, I'm literally only doing one process here.

Anyways, looking at what you've suggested, I didn't realise you could actually run Bash in a step! I'll get this implemented and let you know how it goes next time I make a new release 😄

Thanks for all your help!

[thebrightspark]

Actually looking back, about this:

It would be more efficient to amalgamate the jobs into a single one. My perspective is that jobs should only be separated if they can be executed concurrently.

I realised I did it because I have the publish job running with the matrix. Does that not run each in parallel?

EDIT: Oh actually don't worry, I just realised you moved the build step inside the matrix! I didn't realise you could use the matrix variable in the way you did 😄