Test app/depot configurable with secrets and add DLC support (doesn't use appId + 1 for first depot)

[bilalakil]

Changes

• firstDepotIdOverride input added
  • This is needed to support DLCs on Steam which don't follow the appId + 1 pattern
  • Added this now because the current suggestion in Setup a Steam App Id for tests #18 is to use a DLC to get tests passing
• Add $TEST_APP_ID and $TEST_FIRST_DEPOT_ID_OVERRIDE secrets so the test app/depot can be configured without needing to change code

Checklist

• Read the contribution guide and accept the code of conduct
• Readme (updated)
• Tests (updated)

[bilalakil]

I've created a new DLC and Steam Build Account and confirmed tests are passing with all that:
https://github.com/bilalakil/steam-deploy/actions/runs/1623757569

I'm happy to offer the use of that DLC and build account for this repo if desired, as discussed in #18

[bilalakil]

Also confirmed that standard appId-based depot IDs (without specifying any override) still works with my other private app

[bilalakil]

Hmm I set up all the secrets needed to get the test passing on this PR, but it didn't work. It looks like the input is being ignored for some reason.

Here's the input in this PR:

Run ./
  with:
    buildDescription: v0.0.1
    rootPath: build
    depot1Path: StandaloneWindows64
    depot2Path: StandaloneLinux64
    releaseBranch: prerelease

Here's the input in the source commit on my forked repo:

  with:
    username: ***
    password: ***
    configVdf: ***
    ssfnFileName: ***
    ssfnFileContents: ***
    appId: ***
    firstDepotIdOverride: ***
    buildDescription: v0.0.1
    rootPath: build
    depot1Path: StandaloneWindows64
    depot2Path: StandaloneLinux64
    releaseBranch: prerelease

Same commit, same secrets 🤔 I guess GitHub Actions is being a little funny. Might sort itself out after merging?

[bilalakil]

I guess it kinda makes sense though. If secrets were used in arbitrary PRs, then it'd be easy for strangers to echo them out somehow and "steal" them.

Indeed, this is intentional, just found this in settings:

Secrets are not passed to workflows that are triggered by a pull request from a fork.

[bilalakil]

Considering this, I've added a new commit which disables running the test workflow on PRs since it can't possibly pass ever, I think 🤔

[webbertakken]

The primary branch (main) is the source of truth for the workflows.

Actually the PR workflow passes if one of us core maintainers pushes a change, as the secrets are allowed to be used.

[webbertakken]

This would extend the public API of this action.

Is there no way to just use the recommended approach from steam themselves?

[bilalakil]

I'm not familiar with this. What recommended approach are you referring to?

[webbertakken]

With public API I simply mean what you configure the action with:

  with:
    parameter: value

In general, as part of GameCI Actions philosophy we try to limit the amount of parameters that the end-user would have to understand to a minimum. We always try to deduce information internally inside the action where possible.

Perhaps it's not possible to do that in this case, but I don't have sufficient context to judge this. This is why I'm asking as a question.

[bilalakil]

Ah sorry I understand the aversion to modifying the public API - my question was more about this part:

Is there no way to just use the recommended approach from steam themselves?

I'm not sure what recommended approach from Steam you're referring to here

[bilalakil]

In terms of context, what I've learned in this exercise is that a certain configuration of DLC in Steamworks results in a first depot whose ID is not appId + 1, but rather is exactly equal to appId, so the existing functionality wouldn't have worked for that 😢

Even thought this DLC was just made for testing, it's highlighted a situation that real users can face if they're using Game.CI to build/deploy some DLC.

So I added this as a backwards-compatible option for handling this DLC case, and possibly other cases too that we're still not aware of.

[webbertakken]

Ideally we would not mix multiple concerns in the same PR, but I understand it might be needed to get the workflow running.

LGTM