Add GH Action Workflow to push master and development branches to Steam Workshop

[macinsight]

This proposed enhancement suggests the addition of a GitHub Action Workflow to streamline the process of pushing changes from both the 'master' and (hopefully upcoming) 'development' branches to the Steam Workshop. Currently, this process requires manual handling by Coavins. Automating this workflow can significantly improve efficiency and reduce the risk of oversights during the deployment process.

I'd propose the following changes:

• creating a workshop.yml file that publishes to Steam Workshop upon a new release being created from the master branch

For this workflow to be efficient, the following step-by-step workflow should be discussed below:

• shifting the merging of PRs from other community members to a newly created development branch where issues get ironed out and testing takes place.
• Publish the development branch to a new Steam Workshop Item named "coavins-firearms-repair-git" or similar
• Once those are ironed out, reviewed and all, merge to master
• package a new release describing additions
• By automation, publish this new release on Steam Workshop

Happy to hear your input.

[macinsight]

After testing, this seems to publish to the Workshop at least

I'd update the workflow to only act on PRs to the develop branch if we're going the route proposed above, for the testing version at least. I'd then add another workflow file that does the same, only for packaged releases from master/main

[macinsight]

Okay, my additions in my fork (see below) broke something and the runner isn't running.

Trying to have it only push on the following conditions

• Changes are made to contents of "src" folder
• PR has been closed and is being merged
• Target branch of the PR is develop

I'll do some more testing, should be a way to fix that.

Edit: Turns out that PR stuff in actions when run against a fork is being forcibly run agianst the main repo, not the fork, according to docs. Not ideal, that.

[macinsight]

Preparing update...ERROR! Failed to update workshop item (Failure).

Progress, 'cause it's now using the worker when told to, and authenticating against Steam, but still, no dice. Uploading through PZ works. I'll investigate furhter.

[macinsight]

After figuring out how to set logging options for steamcmd for a local test-build (Note: It's steamcmd +api_logging 1 1) and then checking the workshop_log.txt in the Steam Logging directory, I may have found the issue:
Upload workshop item 3094919253 failed (Build for workshop item has no content)

[macinsight]

I'll put it in writing, I'm an idiot. Forgot to tell the action to actually checkout the repo. But I learned a lot about Action workflows, which is cool.

Now it's working, has been squashed into my master branch.

[macinsight]

This has been thoroughly tested and implemented in a PR awaiting approval, #43
@coavins: Ready to merge.

[coavins]

I think this would be a great change, and your workflow described above looks solid. We should probably open a develop/development branch regardless of the CI/CD automation.

What concerns me about the automation is that the Steam workshop does not appear to support any kind of PAT authentication. Is there really no way to do this without using your actual Steam account credentials and messing with 2FA? It doesn't even look like you can delegate upload permissions to another account. I don't know if I feel comfortable using this as long as it requires access to my whole entire Steam account.

[macinsight]

There are multiple solutions to the security predicament.
Steam does not allow for Personal Access Tokens, but allows for additional accounts to be added in differing capacities to workshop items.

Thus a way to resolve this would be to create a steam account that gets added as "Developer" to the item, then the Publishing automation uses that account, having its credentials added as repository secrets like I have with mine. This is generally considered secure (enough) Doesn't work with Steams permission system, 90% of the actions are available only to Item Owners, not collaborators/contributors (Edit: This needs verification, see comment below)

Another way to solve this, while having Steam Guard enabled and having releases go through your account, would be to switch the automation and add the seed for 2FA (Some automations support this, I'll test them) as a GH Repository Secret, same storage for the username and steam account password. If that is sufficiently long, I personally see an acceptable risk. GH Repo secrets. You need admin access to create them, they get encrypted with SHA256, and nobody ever sees them again or is able to modify them, the only action available is to delete them.

We could place restrictions around what specifically gets published to the Workshop by having the action only run under set conditions like outlined above, mitigating the risk of the entire ordeal in regards to stuff like someone publishing unvetted code to the Workshop in your name. That's currently the best I can think of where we can compromise usability and security.

Though as a whole, the entire permission system surrounding Steam and the Workshop is utterly fucking archaic and anachronistic and should be tossed into a fire and rebuilt.

[macinsight]

Actually, there is at least recent enough (As of this year) mention of allowing contributors to update an Item on the Bohemia Forums. If anyone fucks around with Steam Workshop, it's ArmA 3 Mod devs.

I'll send you a friend request on Steam and we can test that with the development build I got there, alright?

[macinsight]

Closed due to concerns about Steam handling authencation.

[coavins]

Thank you @macinsight for kicking this off - you probably noticed, but I moved the mod to another account and I'm using that account for the CI workflow. There is one that runs nightly for a separate workshop item (https://steamcommunity.com/sharedfiles/filedetails/?id=3103482033) and another one that runs when a v* tag is pushed.

This will really save some time and energy in the long run when it comes to pushing updates, so thanks again!

[macinsight]

Oh, sweet! Now I can crowdsource the missing items, hah! Looks like the nightly item is currently hidden, could you add me as a contributor for that item as well so I can subscribe and test stuff without having to worry about Zomboid not liking my symlinks from src to ~/Zomboid/Workshop?

[macinsight]

Actually, what's the source branch for the nightly one? We could use the development branch for that, if it's currently using master.