Add switch to disable github release body override

In version v3.4, when the action is triggerred by release creation, the body of the existing release will be override to the changelog field from the action input

mc-publish/src/platforms/github/github-uploader.ts

Lines 129 to 136 in 69d94c5

    
           private async updateRelease(request: GitHubUploadRequest, releaseId: number, api: GitHubApiClient): Promise<GitHubRelease> { 
        
               return await api.updateRelease({ 
        
                   ...this._context.repo, 
        
                   id: releaseId, 
        
                   body: request.changelog, 
        
                   assets: request.files, 
        
               }); 
        
           }

v3.3 does not have this issue

Currently here's no option to switch this release body override off, causing the release body being modified unexpectedly. Please add a switch for that

In case it's not obvious enough, I have a github action to publish mods to both curseforge / modrinth, and update asset to github release. The changelog is generated dynamically at runtime, and I want to use the generated changelog only for curseforge / modrinth publishing, and keep the existing github release body untouched

          changelog: |-
            ${{ format('{0}{1}', github.event.release.body, steps.get_release.outputs.body) }}
            
            -------
            
            Build Information
            
            - File name: `${{ steps.file_info.outputs.name }}`
            - SHA-256: `${{ steps.file_info.outputs.hash }}`
            - Built from: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}

It works well in v3.3, but not in v3.4, cuz v3.4 will modify the release body

Example action and corresponding release:

Example workaround for this issue: Fallen-Breath@d617aae

In versions v3.3 — to which I believe you're referring since v3.4 doesn't exist yet — I addressed and resolved an issue that had been overlooked: the changelog and github-changelog inputs weren't affecting the body of an existing GitHub Release. This is no longer the case; everything now operates as expected.

I suspect you might be experiencing some confusion because the behavior you'd been relying on was altered, even though that behavior was incorrect. There isn't an issue per se; mc-publish is executing precisely as instructed. If you desire different results, the request should be tailored accordingly.

You're using the top-level changelog input, which means "set the changelog on all platforms to the provided value". However, your actual requirement is "set the changelog on Modrinth and CurseForge to the provided value". This can be translated into the following configuration:

modrinth-changelog: My custom changelog.
curseforge-changelog: My custom changelog.

However, following the DRY principle, you'd need to save your changelog into a separate variable. Let's make it easier and rephrase your need as "set the changelog on every platform to the provided value, but retain the current GitHub changelog". This can be expressed as:

changelog: My custom changelog.
github-changelog: ${{ github.event.release.body }}

So, to reiterate, there isn't an issue requiring new inputs, switches, or especially workarounds. Simply instruct the action to perform the task you want, and it will readily comply :)

Ah yeah I was using the wrong version in the issue description

Thanks for pointing out that there's a way to specify changelog for each platform separately, this should resolve this issue correctly

Besides that, I still have a suggestion for this issue: Add a document for platform-specified changelog input like modrinth-changelog in README, or just mention that you can specify platform-specified input by adding a curseforge- or github- prefix. I didn't know that it's doable, before your reply was given

Besides that, I have a suggestion for this issue: Include a section in the README for platform-specific changelog inputs like modrinth-changelog, or, make it clear that platform-specific input can be specified by adding a curseforge- or github- prefix. I didn't know that it's doable, before your reply was given, or it's just me skipping something from the README

Actually, a section dedicated to target-specific inputs already exists in the README. This section was established from the very moment I officially introduced support for such inputs (even though the functionality was always there, I hadn't fully polished it until the v3.1 release).

Please note that any top-level property (name, version, dependencies, files, etc.) can be used as a target-specific one. This allows you to customize mc-publish to better meet your individual preferences and requirements. To illustrate, let's take a look at the following configuration:

# Shared top-level properties
files: build/libs/!(*-@(dev\|sources\|javadoc)).jar
dependencies: |
  sodium@0.4.10(required){modrinth:AANobbMI}{curseforge:394468}#(ignore:curseforge)

modrinth-id: AAAAAAAA
modrinth-token: ${{ secrets.MODRINTH_TOKEN }}
# The name of your mod, specific to Modrinth
modrinth-name: Modrinth Mod
# The files for your mod, specific to Modrinth
modrinth-files: build/libs/*.jar
# The dependencies for your mod, specific to Modrinth
# Note that it's possible to use project ids instead of slugs
modrinth-dependencies: |
  AANobbMI@0.4.10(required)

curseforge-id: 0
curseforge-token: ${{ secrets.CURSEFORGE_TOKEN }}
# The name of your mod, specific to CurseForge
curseforge-name: CurseForge Mod
# The dependencies for your mod, specific to CurseForge
# Note that it's possible to use project ids instead of slugs
curseforge-dependencies: |
  394468@0.4.10(required)

I agree that the need for a comprehensive wiki for this project is pressing. Rest assured, I am actively working towards that goal. Currently, due to my move to a new apartment, I'm not able to dedicate as much time to larger tasks as I would like. However, in general, I am focused on it. With the release of v4.0, I aim to provide a detailed wiki that outlines all the capabilities of mc-publish!

Since the main problem of this issue is resolved, I'm closing it.

See #90, the “release body overwrite” feature might cause some unwanted issues

	private async updateRelease(request: GitHubUploadRequest, releaseId: number, api: GitHubApiClient): Promise<GitHubRelease> {
	return await api.updateRelease({
	...this._context.repo,
	id: releaseId,
	body: request.changelog,
	assets: request.files,
	});
	}