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.

[Hmph, my git-sendemail-foo is still suboptimal - the following
was intended to be sent as introduction to the patch I just
sent but din't come through.]

I have a bad habit of rethinking things until they seem
"perfect", whatever this means.  Likewise here, where I
understood that package termfmt is meant to handle output only
and, hence, not very well fitted to host anything related to
stdin.

So I placed the two variables isStdin/outTerminal into the main
package instead and added some backward-compatible initialization
logic to package termfmt.

Read from $EDITOR only if stdin is on a terminal.  Default
command flag stdin accordingly.  Document reading of input in the
overall description and not per command.
---
 builds.go             |  4 ++--
 doc/hut.1.scd         | 45 +++++++++++++++++++++++--------------------
 git.go                |  2 +-
 graphql.go            |  8 +-------
 hg.go                 |  2 +-
 lists.go              |  6 +++---
 main.go               | 14 +++++++++-----
 meta.go               |  2 +-
 pager.go              |  3 +--
 pages.go              |  2 +-
[message trimmed]

I have a bad habit of rethinking things until they seem
"perfect", whatever this means.  Likewise here, where I
understood that package termfmt is meant to handle output only
and, hence, not very well fitted to host anything related to
stdin.

So I placed the two variables isStdin/outTerminal into the main
package instead and added some backward-compatible initialization
logic to package termfmt.

In addition, in hut.1.scd I sort of factored out the per-command
description of how reading input works into the description
section, shortening the per-command descriptions accordingly.

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

> Please remove the last variable. It is redundant and introduces an unnecessary
> syscall.
> [...]
> Nit: We don't really need this function in addition to IsTerminal, but
> it should be fine to keep it, just return "isTerminal" here.

I agree with your suggestions and will implement them.  One follow-up,
though:  From a cursory check it seems that most IsTerminal checks done
in hut are quite clearly related to *either* STDIN *or* STDOUT.

For example, the use case I started this thread about is about STDIN
being on a terminal.  The following function is about STDOUT being on