Allow getting files from GitHub release artifacts

[srnyx]

If a workflow was triggered by a release being published, it should be possible to get the project's files from the release's artifacts. This way it wouldn't have to be rebuilt in the workflow as they'd be manually uploaded when creating the release, y'know? Or, even better, the ability to add the built files from the workflow to the already existing release.

[Kir-Antipov]

If a workflow was triggered by a release being published, it should be possible to get the project's files from the release's artifacts.

Thank you for your suggestion. While I appreciate your interest in improving the project, I have a few considerations to share.

Firstly, the project is already pretty well-established at this point in time, and any changes we make must be carefully considered to maintain its stability and usefulness. Adding new features, especially obscure ones such as, for example, extended glob syntax for files not located on the current machine (a solution that could solve the issue exactly how you describe it), could complicate the project unnecessarily.

Secondly, your suggestion seems to be addressing a need that can be met by existing tools. You can download files to the machine executing the action, and then use the files input as usual. Here's an example config that does exactly that:

- name: Download
  uses: dsaltares/fetch-gh-release-asset@master
  with:
    version: tags/${{ TAG_NAME }}
    file: my-mod-.*[.]jar
    regex: true
    token: ${{ secrets.GITHUB_TOKEN }}

- name: Publish
  uses: Kir-Antipov/mc-publish@v3.3
  with:
    files: my-mod-*.jar
    # ...

Thirdly, and perhaps most importantly, I have to express my strong skepticism towards features that might encourage unsafe practices. Manual project building and file propagation to platforms like CurseForge or Modrinth is highly discouraged. This approach was, in fact, the vector for the notorious Fractureiser malware - developers unknowingly infected their users by building mods on their compromised machines and manually uploading the infected files to public platforms.

So, it's highly recommended to use the safe environment provided by Continuous Integration systems for building your mods and propagating the build files from there. It's not only easier for you, but also significantly safer for players who trust your work. If, for some reason, you still need to propagate manually built files, you can use the example provided above. There's no need to add new features to mc-publish for this purpose.

Or, even better, the ability to add the built files from the workflow to the already existing release.

To be quite frankly honest with you, I'm having a bit of trouble understanding what you're trying to say. Since the inception of this project, the optimal scenario that this action was designed for involves creating a release, which triggers mc-publish, which, in turn, appends the files that were automatically built by your CI workflow to the existing release and propagates them to other platforms. Is this what you're referring to, or have I misunderstood your point?

[srnyx]

Thank you for the in-depth reply! I'm not sure how I glanced over the ability to use other tools to accomplish what I want, as now that I think about it, it's 100% possible to do safely using the Upload files to a GitHub release action. I'm not sure why I suggested that last part because it doesn't really relate at all to mc-publish, and the action to do what I was explaining is exactly what the action I linked above does.

[Kir-Antipov]

So, I'm still interested, how is using upload-release-action different from mc-publish in your case?

[srnyx]

So, I'm still interested, how is using upload-release-action different from mc-publish in your case?

I would use them together. First, I would publish a release (without any artifacts), then the workflow will build my project and use upload-release-action to upload the project's files to the published release. Then, it'll run mc-publish using the files the workflow built earlier. I would just have mc-publish create the release, but I like typing out the release's name and description/changelog myself.

[Kir-Antipov]

You are literally describing the initial use case for which I built this action.

Check out my workflow, which accomplishes exactly what you're aiming to achieve (in like one line).

There is no need to create a release with mc-publish. To provide further clarity, mc-publish wasn't even capable of performing such task prior to v3.0. This meant that you were required to create the release yourself. Nowadays it's just more flexible - you can create new releases with it or use already existing ones.

[srnyx]

Check out my workflow, which accomplishes exactly what you're aiming to achieve (in like one line).

Oh, that won't create a new release or anything? It'll upload the files to the release that triggered the workflow?!

[Kir-Antipov]

Yup. My original objective with this action was to re-distribute a GitHub Release to other platforms. Specifically, I wanted to input the new release's name and description, then have my workflow attach freshly built files to it and replicate all these materials to CurseForge and Modrinth. While mc-publish now supports a wider range of scenarios, this initial function remains fully operational, and I personally rely on it too, as you can see.