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

game-ci / steam-deploy

Github Action to deploy a game to Steam

MIT License

227 stars 63 forks source link

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

Closed bilalakil closed 2 years ago

bilalakil commented 2 years ago

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 #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

[x] Read the contribution guide and accept the code of conduct
[x] Readme (updated)
[x] Tests (updated)

bilalakil commented 2 years ago

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 commented 2 years ago

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

bilalakil commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.