I'm not sure if it possible to issue organization based token (not a personal one).
As for visibility, secrets are not visible for pull requests. чт, 22 дек. 2022 г. в 22:57, Илья Шипицин <chipits...@gmail.com>: > there are couple of steps left (no hurry, because "matrix.py" is backward > compatible) > > 1. issue "some kind of token". > either Personal Access Tokens (Classic) (github.com) > <https://github.com/settings/tokens> (no time limit) > or Fine-grained Personal Access Tokens (github.com) > <https://github.com/settings/tokens?type=beta> (1year token) > > 2. add issued token to secrets: > https://github.com/haproxy/haproxy/settings/secrets/actions/new > > 3. add secret definition to workflow, like this: haproxy/coverity.yml at > master · haproxy/haproxy (github.com) > <https://github.com/haproxy/haproxy/blob/master/.github/workflows/coverity.yml#L40-L41> > > чт, 22 дек. 2022 г. в 22:43, Willy Tarreau <w...@1wt.eu>: > >> On Thu, Dec 22, 2022 at 10:32:22PM +0600, ???? ??????? wrote: >> > I attached a patch. It keeps current behaviour and is safe to apply. >> > >> > in order to make a difference, github token must be issued and set via >> > github ci settings. >> >> OK I understand better now, thanks! I didn't know that there was a >> difference between auth vs non-auth. >> >> I'm having a few questions though: >> - where are we supposed to find that token to fill the variable (most >> likely Tim will facepalm and come rescue me here :-)) >> >> - how can we certain that there isn't a risk that this token leaks >> into build logs which are public ? Because that's what I absolutely >> hate with the principle of github insecure tokens, it's that they're >> purely private keys that have to be blindly copy-pasted everywhere. >> >> It would be wise to be certain we don't become the de-facto standard >> github API token provider for all anonymous users... >> >> Thanks, >> Willy >> >
