Meta: Limit IPR check job to the tc39 repository

[gibson042]

This aligns it with the other privileged jobs.

[ljharb]

I had it this way so I could test it on my fork; maybe instead it could check not the repo name, but the presence of the secrets?

[gibson042]

I'm not sure I understand; are you saying that this job should be subject to different conditions than the other privileged ecma262 workflows such as deploy and upload preview?

[ljharb]

Yes - in general, I think an action should be checking for secret presence instead of hardcoding the repo name, but "upload preview" can't ever work for another repo (on the begin side), so that check is correct.

[gibson042]

I think that's answering a different question than I asked. I agree that hardcoding the repo name isn't great, but I see more value in consistency across checks than in updating just one workflow to use a better approach. Regardless, I don't feel very strongly about this so if you make a concrete ```suggestion I'll accept it (or you can just apply a change directly).

[ljharb]

I don't think consistency has much value here; each job is doing its own bespoke thing. I'll add a suggestion, though.

[ljharb]

I ended up having to revert this; apparently secrets aren't available inside if conditionals. We'd have to figure out something more complex to make this job conditional on the secrets, and I prefer not to hardcode it to the specific repo.

If you'd like to try an alternative approach please open up a new PR.

[gibson042]

@ljharb What about the original approach in 919b36d that is aligned with the other privileged ecma262 workflows such as deploy and upload preview?

[ljharb]

That approach would work, but it would limit testing - the reason those specific deploys have that check is because the begin.com service they talk to also has that check.

[gibson042]

Right now this check is generating spurious failures in my own fork repository, and presumably in other forks as well. Where do you think it needs to happen other than tc39/ecma262, and why does the same not apply to the other privileged workflows?

[ljharb]

I test changes to the workflow in ljharb/ecma262 so that I know they pass before landing them here. I failed to do that very testing on this PR, unfortunately.

The other privileged workflows are unique in that they contact a third party service that explicitly rejects, serverside, anything that's not tc39/ecma262.

I agree that spurious failures in a fork are undesirable, I just don't want to prevent testability of the workflow in the process if it can be avoided.

[gibson042]

Can you move that from ljharb/ecma262 to non-main branches of tc39/ecma262? Or possibly to a new fork such as tc39/ecma262-testing?