Re: [hatari-devel] github hatari

Hi Thomas,

Many thanks. I've pulled that change into my fork now and have run the repo-sync.yml workflow manually.

Unfortunately it fails for me (see https://github.com/cdpjenkins/hatari/actions/runs/6129689194) with the following :

The workflow is not valid. .github/workflows/repo-sync.yml (Line: 10, Col: 9): Unrecognized named-value: 'secrets'. Located at position 1 within _expression_: secrets.MIRROR_PAT != ''

I found a GitHub issue that says that secrets cannot be used to condition run jobs (I guess because this might run the risk of leaking information about the secret):

https://github.com/actions/runner/issues/520

I found a few examples online where someone had managed to use the secret to set another (non-secret) variable but I didn't manage to make it work. And I'd be nervous about the risk of leaking information about the secret by doing this.

So I'd suggest one of two solutions:

- Use the repo name to control whether the job is executed (the approach in my original patch);

- Use another non-secret variable to control it... this approach works (see https://github.com/cdpjenkins/hatari/blob/fun-with-secrest/.github/workflows/repo-sync.yml) but it feels annoying to have to set not one but _two_ variables in order to control the sync.

Do you have a preference for either approach?

Cheers,

Chris

On Sat, 9 Sept 2023 at 08:06, Thomas Huth <th.huth@xxxxxxxxx> wrote:

Am Tue, 29 Aug 2023 18:13:21 +0100
schrieb Chris Jenkins <cdpjenkins@xxxxxxxxx>:

> Hi,
>
> Attached is a patch that causes repo-sync.yml to run only on hatari/hatari
> and not on a fork.

Hi Chris,

thanks for the patch! That "if:" statement is a good idea - I've now
committed a slightly different patch, it checks for MIRROR_PAT being set
instead, so that people who would still like to use the automatic mirroring
could continue to do so.
Not sure whether this will work properly though, so in case it does not
work out as expected, I'll switch to your solution instead.

Thomas