Using plain old email you can do all things "Copy on Select 2"
here:

- File issues and enhancement requests,

- post questions or start discussions, or even

- contribute patches with "git send-email" [1].


Some usage notes on this mailing list:

- You do not need to subscribe or register to send email here.
  Just send your email to ~jschmidt/copy-on-select-2@lists.sr.ht

> so perhaps the problem has resolved itself?

It has for one commit and for me at least, thanks.

More data points:

- A comparable build got triggered by a tag push 17 days ago:

    https://builds.sr.ht/~jschmidt/job/1389728

- I can resubmit other builds from the browser UI, so the
  build services seem to be working:

    https://builds.sr.ht/~jschmidt/job/1400083

- Tried re-tagging and re-pushing, nothing doing.

- Modified .build.yml to hard-code GIT_REF to the tag I'm

I just pushed a tag to

  https://git.sr.ht/~jschmidt/copy-on-select-2

which should have triggered a build.

But nothing happened.  At all.

Am I missing something?

On 2024-06-23  12:03, Drew DeVault wrote:

> The keys are still handled in the same manner. I would definitely advise
> you to take pains to prevent the keys from being disclosed in the build
> logs.

Thanks.  Here is my approach to ease the pains for Bash scripts, both
on a per-command level:

  pushx
  secret=$( get my secret )
  popx

and (for curl) on a per-argument level:

Hi list,

Ploum recently provided two "low-hanging fruits" for saving build
resources [1], here is probably another one:

c) In one of my projects I use a .build.yml that basically looks
like this:

[...]
tasks:
  make: |
    # build only for release tags
    if [[ ${GIT_REF-} =~ ^refs/tags/v2\.[1-9][0-9]*$ ]]; then
      cd <project-root> && make <target>

On 2024-06-22  13:28, Jens Schmidt wrote:

> Or, more generally: What is the exact lifetime of that generated
> token?

Ok, just found this thread:

https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C20210930204251.vowt5jkoeiuodzgj@athena%3E

Has there anything changed since then?

https://man.sr.ht/builds.sr.ht/manifest.md#oauth says:

  oauth

  If present, and secrets are enabled for this build, an OAuth 2.0
  bearer token is generated for this build with the given string
  as the list of grants.

Does "for this build" above mean "valid for this build only"?  IOW,
is it uncritical to show that token (and only that) in the build
log?  Is the token still valid in an ssh session open after a
failed build?

Or, more generally: What is the exact lifetime of that generated

On 2024-06-18  21:24, Thorben Günther wrote:

> I have edited it a bit by running "gofmt", because there were some
> unnecessary semicolons.

Thanks for merging and for the pointer - I'm still rather new to Go.

How about a variation of the following to avoid such newbie-isms?
(If you like it, feel free to apply it, if you need a patch - will
provide one, if you don't like it - no need to further discuss it :-)

diff --git a/Makefile b/Makefile
index 90ddaef..e5280cc 100644
--- a/Makefile
[message trimmed]

On 2024-06-10  22:19, Thorben Günther wrote:

> Another option I am considering is adding some backoff/delay between the
> individual GraphQL requests.

Exactly my thoughts!  Starts with a delay=0, sleep for delay milliseconds
after each request, add 100ms to delay after each nth request.  Or
something like that.

>> At least in some case of nested queries like in your pagination patch
>> [2] one could use the count parameter to limit the *overall* number of
>> joined results.
> That would be a possibility, but I am not sure if that behaviour would
> be very intuitive for users.