Workflow and Gradle based publishing setup with changelog system

[IThundxr]

Implements automatic publishing trigged by running a workflow, and then using "me.modmuss50.mod-publish-plugin" on the gradle side of things

For this to actually work some things need to be done:

• CURSEFORGE_API_KEY needs to be added to the repo secrets and set to a curseforge api key from a user with write perms for the sodium curseforge
• MODRINTH_API_KEY same as above, but modrinth, the token should have the permissions "Read User Data" and "Create versions"
• CHANGELOG.md needs to be filled out before making a release, instructions are included inside on how to use it
• This PR currently does not include any automatic version bumping due to the fact that it's not really easy to guess what the next version should be, so developers need to be mindful to update the version either right before publishing, or right after a release has been published

[douira]

Is this ready? Once it is, I would like Jelly and IMS to also review this, and then it would be nice if we could try it out for Sodium 0.8.10, which is an upcoming bugfix release.

[IThundxr]

Is this ready? Once it is, I would like Jelly and IMS to also review this, and then it would be nice if we could try it out for Sodium 0.8.10, which is an upcoming bugfix release.

Mostly yes, it just needs to be tested and when this is merged 2 secrets for the curseforge and modrinth api keys will need to be added

[douira]

You can mark the PR as ready for review when you think it's complete and correct. Thanks for the work so far!

[jellysquid3]

The workflow file needs to be updated so that it runs on the restricted prod environment, otherwise it can't obtain the access tokens during build.

There is a current example of this here.

[jellysquid3]

Related, but not blocking: #2174

This greatly reduces the risks of malicious code getting into the CI/CD and gaining access to the credentials.

[IThundxr]

The workflow file needs to be updated so that it runs on the restricted prod environment, otherwise it can't obtain the access tokens during build.

There is a current example of this here.

Already does that over here https://github.com/CaffeineMC/sodium/pull/3575/changes#diff-232ead425069ad86b523a739aa18b77f9088cd61a4b40c6a374d9774ff78cfc8L13-L14

[jellysquid3]

Oh, OK. Somehow I missed that.

[shihyeon]

If you want to fix the publish order of Fabric and NeoForge, you need to write the code accordingly. If you run a dry run, you will see that the order is not guaranteed. If this does not bother you, you can ignore my opinion.

[douira]

I think the publish order doesn't have any significant importance to us, thanks for pointing it out though. Since we've approved it, do we need to insert the API keys into the GH Actions before we merge this?

[shihyeon]

API keys are required when running this workflow.

[IMS212]

Looks good.

[douira]

Closes: #3404
Also there's a merge conflict now (idk why).

[jellysquid3]

The production environment has been modified on the organizational side to supply the expected tokens now.

[jellysquid3]

I think the publish order doesn't have any significant importance to us, thanks for pointing it out though...

It would be nice if Modrinth/CurseForge didn't randomly shuffle the order between NeoForge and Fabric updates, though. How difficult is it to prevent this?

[shihyeon]

It would be nice if Modrinth/CurseForge didn't randomly shuffle the order between NeoForge and Fabric updates, though. How difficult is it to prevent this?

I use it like this. (full code)

    val publishTasks = tasks.withType<me.modmuss50.mpp.PublishModTask>()
    val fabricPublishTasks = publishTasks.matching { it.platform.name.contains("fabric", ignoreCase = true) }
    publishTasks.matching { it.platform.name.contains("neoforge", ignoreCase = true) }.configureEach {
        mustRunAfter(fabricPublishTasks)
    }

[douira]

Merging as the ordering thing isn't blocking. @IThundxr can maybe look into it in a follow-up.