#vito catching up on modules v2

1 messages · Page 1 of 1 (latest)

edgy sluice
#

Collections look really neat! They're ALMOST a good fit for interfaces, but don't actually fit since they have generic key/value types.

Using interfaces would look something like this:

interface Collection {
  keys: [String!]!
  get(key: String!): Node
}

Then DagQL will automatically add implements Collection for any objects implement that interface, making that information available at the schema level. (Note: Node can be a concrete type on the implementing side.)

The main advantage is then you can pass a Collection around to other code, rather than being something only interpreted by Dagger. Having GraphQL inspection able to tell you which types implement Collection is also kind of neat.

Not proposing with any conviction, just exploring new capabilities

plush vessel
#

@edgy sluice one cool possible applications of collections - perhaps we could change how we publish Github Checks... instead of "go:test-all has failed" (grouping by check function) we could group by go module, or even by go test suite 🙂

#

In theory we could go all the way to "by go test" but maybe that's too much for Github checks API?

edgy sluice
#

yeah there's a pretty low limit for GitHub checks, i don't think per-module or per-suite is even viable

#

(but still cool to think about)

plush vessel
#

Or we could really abuse the intent of the Github Checks API, and do:

  • 1 failed check per actual failing artifact, with maximum precision (eg. 4 failed go tests = 4 github checks with module=X test=Y)
  • All green checks across all modules get rolled up in a single "everything else is green" check 🙂
#

Basically we would be giving the finger to Github expectation that checks are mostly static... While still fitting within the limit

#

We could even dynamically adjust the level of precision specifically to fit in Github's allowed limit

#

Like if you have 5 individual failing tests, we show that + 1 "everything else" green check (6 total).

If you have 999 failing tests across 3 modules... We automatically adjust and show 3 failing go modules + 1 "everything else green"

#

I mean imagine if Github showed you the actual test suite that failed directly in the PR.. and when you click, you get straight to the fialing tests in that suite guy_fieri_chef_kiss

edgy sluice
#

hmm but there's no way to remove checks, and you'd want to see them pending first

plush vessel
#

We would always have the "everything" check pending... Then as things fail we compute what red checks to show JIT

edgy sluice
#

ahh got it

plush vessel
#

(I'm figuring out the answers as you ask the questions to be clear 😛 )

edgy sluice
plush vessel
#

real world example just now: by manually following my 3 failed checks, then manually navigating to "test view" ( chefkiss ) I quickly realized all the failing tests are git-related, and most are bitbucket. I am now concluding there was some networkgin glitch between namespace and bitbucket.

Imagine if I could have figured that out without leaving the PR page!

edgy sluice
#

@plush vessel this part:

keys must be an exposed field
get must be an exposed function
keys can also be a function, right? It says 'field' a few times so just clarifying

#

I'm fuzzy on how batching works - what would it look like for a module to implement runTests?

plush vessel
plush vessel
#

basically a batch function is a design no-op: you just write a regular function on the collection type

#

it will shadow a function with identical name on the item type