Re: [hatari-devel] github hatari

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Sat, 9 Sep 2023 09:11:58 +0100
schrieb Chris Jenkins <cdpjenkins@xxxxxxxxx>:

> 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 != ''

Yes, I just got the same failure in my repo :-(

> 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

Ok, thanks, good to know!

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

Let's keep it simple, I've applied your solution now. Thanks!

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/