github actions dx issue: forks and branches

[gregsadetsky]

hey rcade team,

just a small thought/issue that you may want to think about - this may be a very very very very edge case, but still:

• I forked Claire's miRCo repo - my fork is here
• every time I push on my repo, the github actions will run. same thing for Claire's upstream repo
• in the Games API endpoint, I see that the game appears with

"git":
    {
        "ssh": "git@github.com:gregsadetsky/miRCo-engine.git",
        "https": "https://github.com/gregsadetsky/miRCo-engine"
    },

because I github-actions-deployed it first, and since both my fork and Claire's upstream both declare the game with the same gameid/name, "mirco"

• just something maybe to mull about - or maybe provide best practices for? should I... add something to deploy-rcade.yaml so that it takes the github user+repo in account in the game name? ie should the github action rename the name in the manifest for "mirco (dev - greg)" to make sure that it appears/is pushed as a separate game?
• I guess the same question / issue would happen for anyone who develops on a branch - their github action would also run and would overwrite the game from their main branch..? (I guess that's not true since the github actions has branches: [main, master] in it)

[gregsadetsky]

probably that this would work?

      - name: Modify manifest for forks
        if: github.repository != 'clairefro/miRCo-engine'
        run: |
          jq '.name = .name + "-${{ github.repository_owner }}"' rcade.manifest.json > tmp.json
          mv tmp.json rcade.manifest.json

no need to add this into the main RCade code/flow I guess... but curious on thoughts. tyyyyyyyy

[fcjr]

I've added a check for repo owner and manually migrated ownership of the miRCo game to Claire's repo as an immediate fix.

This fixes the edge case where a user forks an existing game to make a PR (as the action will fail), users also have to explicitly enable GitHub Actions on forks.

We still need to handle the "contribute RCade support as a fork" edge case as the fork will almost definitely take ownership of the game. I can see a few solutions to this:

1: long term approach would be to add a UI on the website to manage "Trusted Publishers" and automate the initial setup of one via the rcade create cli (much like pypi trusted publishers). This has been the long term plan as we'd need this to support games that are hosted in organizations, but I'm wondering if we can avoid it for a while while we focus on finishing the game development and in-hub experience.

2: a shorter term (and maybe a fine solution?) would be to allow users to set the "owner repo" in the game manifest so that our action can read it and simply skip the deploy step if you are not on the owner repo?

Either or those seem reasonable? I'm not crazy about adding any user facing logic to the action-deploy step or conditionals in the generated workflow.

@gregsadetsky, @roobscoob any thoughts?

[gregsadetsky]

option 2 & the PR seem fine to me

it feels like most folks won't fill out these fields (and it would suck to have to fill them out for the manifest to work), so... probably that future fork deployments will go through this bit of confusion (i.e. like when I accidentally took over Claire's repo)........ but this seems quite edge-case-enough that... it's ok? for now?