~emersion added enhancement 2 years ago

~jschmidt 10 months ago

+1 from my side if this would match what I describe here.

Actually, (almost) the first thing I have been looking for in hut was the --json switch...

Thanks.

~emersion 10 months ago

The main issue is figuring out which fields to expose. If we don't need a field for the pretty-printed version, how do we deal with users who need it for the structured output?

~jschmidt 10 months ago

I haven't been checking the sources and my POV may be naive or not suitable for the current code. But my intuitive reply would be: "Keep pretty-printed version unchanged and max out fields for the structured output."

Ah, I guess the problem is in the GraphQL, which you probably have carefully designed to match the fields of the pretty-printed version. Or probably the pretty-printed version is even automagically created according to the structure of the GraphQL?

~emersion 10 months ago

The GraphQL requests have been crafted to only fetch the fields that the pretty-printed version needs. It's not automatic, the GraphQL requests are written by hand.

If we start exposing a field via the structured output, and end up no longer needing it from the pretty-printed version, then this will break any script relying on the structured output.

Additionally, it's possible that a script needs a particular nested field. Having to perform two hut calls for this case is annoying.

I think ideally scripts would declare which fields they need exactly? But then that's very similar to just writing the GraphQL query.

~jschmidt (edited) 10 months ago

I think I get your points. Let's try another approach and focus on hut graphql only.

So here is what triggered me chiming in:

curl \
  --oauth2-bearer "$oat" \
  -F operations='{ "query": "mutation boo( $repoId: Int!, $revspec: String!, $file: Upload! ) { uploadArtifact( repoId: $repoId, revspec: $revspec, file: $file ) { id } }",
                   "variables": { "repoId": 12345678, "revspec": "v1.2", "file": null } }' \
  -F map='{ "0": ["variables.file"] }' \
  -F 0=@xxx.tgz \
  https://git.sr.ht/query

This took me quite some to work out, being new to GraphQL and that particular cURL syntax, in particular because there are a lot of items referring to each other in such a command. Admittedly, the output of that query is not very interesting, and the output of the pretty-printed hut artifact upload equivalent isn't, either. But probably that example is useful, anyway, because it features a mutation, variables, and a file upload.

So would it be probably feasible/reasonable to extend the hut graphql command so that it could grok something along the following:

hut graphql git << 'EOF' | jq '.id'
mutation boo( $repoId: Int!, $revspec: String!, $file: Upload! ) {
  uploadArtifact( repoId: $repoId, revspec: $revspec, file: $file ) { id }
}
"variables": {
  "repoId": 12345678, "revspec": "v1.2", "file": @xxx.tgz
}
EOF

or, even more concisely and somewhat more shell-ly:

hut graphql git repoId=12345678 revspec='"v1.2"' file=@xxx.tgz << 'EOF' | jq '.id'
mutation boo( $repoId: Int!, $revspec: String!, $file: Upload! ) {
  uploadArtifact( repoId: $repoId, revspec: $revspec, file: $file ) { id }
}
EOF

Again, GraphQL is new to me and my proposals not necessarily appropriate ... and this would be probably a new issue. Just let me know if I should open one.

~emersion (edited) 10 months ago

With today's hut graphql, I believe your query would look like this:

hut graphql git -v repoId=12345678 -v revspec=v1.2 --file file=xxx.tgz <<'EOF' | jq '.id'
mutation ($repoId: Int!, $revspec: String!, $file: Upload!) {
  uploadArtifact(repoId: $repoId, revspec: $revspec, file: $file) { id }
}
EOF

~jschmidt 10 months ago

Uh, I should have read the man page better. Thanks.

Given these options and command hut graphql in general I don't see a need for structured output for the other commands, so I'm out of here.

Thanks again.

~mcepl (edited) 6 months ago

I would still like --json option, but without that I am just completely lost in generating GraphQL queries. Would it be possible to get something like general --verbose or --debug option, which would show on stderr GraphQL being used (even better if it was in the form ready to be used with curl)?

Currently, I need a machine-readable list of labels and hut todo label list -t tracker is mostly unusable and/or incomplete (I don’t want to parse colour values from ANSI hex codes).

~jschmidt 6 months ago

Would it be possible to get something like general --verbose or --debug option

Getting working examples from hut by means of some --debug option really would be nice, so +1 from here.

~xenrox 6 months ago

I have opened up a new issue #48 for the "debug mode". Will implement something and then we can discuss there if it is useful or how to improve upon it.