Unclear changelogs

[yogwoggf]

Issue

Imagine being a server owner and wanting to see exactly what has changed in the latest wire update. Say one of your player complains about some bug, and you're not very sure how this bug happened. One obvious course of action is to look at the workshop changelog! The only place where Wiremod is packaged!

That description provides no information to anyone involved.

Potential solution

Use conventional commits to easily give more information to each commit. Then, use commitlint and husky to make sure each contributor properly names each commit.

Now that we have @Vurv78 's workshop deploy action, we can easily compile a list of commits since the last update and make a changelog that only consists of the fix and feat commits.

I'd also recommend ONLY pushing to the workshop for fix and feat commits since they will actually provide changes in how Wiremod works. That would also greatly reduce the amount of updates server owners have to deal with on each server boot.

[yogwoggf]

There's also an alarming amount of unclear commit names in Wire

[yogwoggf]

I also think that if server owners knew which commits caused a bug then triage of issues would be much faster.

[thegrb93]

Pinpointing a buggy commit is what 'git bisect' is used for. You just have to describe a bug and when you think the bug started happening and git bisect will find it very quickly.

Doing so by name of change is much slower.

[yogwoggf]

A server owner likely does not know what git bisect is, let alone have an installation of git. However, my suggestion will make git bisect much more efficient. We'd be able to tell a good commit from a bad commit from a simple glance at the changelogs if they were how I proposed them to be. If something bad starts happening after a update, then we know the last commit from the previous update is a good starting point by using the changelog.

[yogwoggf]

@Vurv78 @thegrb93 Any updates?

[vurvdev]

We'd have to stop squash merging to deal with this

[yogwoggf]

That doesn't seem like a bad thing. If we do implement the proposed solution then any bisecting would be benefited since the fine-grained commits will probably contain more specific changes (e.g 5 or so lines compared to a squashed commit which can be massive)

[thegrb93]

We'd have to stop squash merging to deal with this

No, you could just replace the squash commit text with the PR title or something

[yogwoggf]

We'd have to stop squash merging to deal with this

No, you could just replace the squash commit text with the PR title or something

That would.. destroy the benefits of just merging a PR with a merge commit if we were to lint all commits, that way every wire update changelog would actually have every commit that did some change.

[thegrb93]

We don't want every commit someone's made in their branch in the baseline. A single commit with the main update they made should suffice.

[Anticept]

We had a tool that stopped working a long time ago that would grab commit information and compile it for updating the workshop. However, the person that maintained that system is long gone and we never got information on how he set it up.

Implementing such a system is welcome if someone wants to volunteer to do that. Until then, I'm not going to do all that by hand for workshop updates; workshop always has been a secondary concern for wire anyways.

I could grab the commit hash and plug that into updates and just link it to commit history, but that's as far as I'm willing to take it. Someone's gotta volunteer to develop the system to make it any more featureful than that.

[Aws0mee]

I personally don't see any issue with how it currently is. For my server I just use the github version and update it every so often or whenever I see an important change.