Re: [hatari-devel] github hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] github hatari
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sat, 9 Sep 2023 08:46:05 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1694249168; bh=07QRzF7YstF8eJtFyYNPO+YoIfOmf4U77nI+0QD7X2Q=; h=Date:From:To:Subject:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=qioRvrBnJqnjCPHd2klimreNj3M93Pb2AeKip0dJsN5dcSvc+C1bdrLkZfDjN5pdh fbfY/Zic3JrGSMwThrv4C7DTI8Zn/Gbb9CNFyRt40s9csACW/4779caDRw9mLWSxBA HzlFPXEXqKLQm1wMewPnMIj552mwUCrsYZdkpNhXR3cE7fzfMypXGnoJaMkKuOX9O4 ej5k3vNzyWVcV9KaF9WPe2LjPyfAJOWmf/cQ6HRtRM2aZrpifkWPABVlZWrsjSZ/MG 72CMLzSHumSnNiVnRBjk6cpc3Z+Y50g/kMf64s1Lt2vbMbLGu9F685ZgJENa/EZ/87 0VjQspXvRERgQ==
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