https://linen.dev logo
Join Slack
Powered by
What do you think of these badges for connector bu...
# contributing-to-airbyte
j
What do you think of these badges for connector build status?
u
Is it clear what the colors and numbers mean @s and @charles?
u
oooh. pretty.
u
i actually don't think i know what yellow means.
u
well
u
Also what should we say if it’s not certified?
u
just no message?
u
i assume green means last build passed. red means last build failed. i don't know what yellow means.
u
I was thinking yellow would be the most recent one passed but it has at least one failure in the last 10 builds
u
i think i would just do green and red then. i think that's too nuanced.
u
that or you need to explain it whereever these get posted.
u
but it's not self evident (at least for me)
u
I think I’ll document it. It isn’t self evident but it’ll make a dashboard more scannable
u
👍
u
the different categories are: Alpha, beta, Airbyte certified
u
or actually, let’s just make an alpha, <blank>, and AB certified
u
@s should we add that as a field to SourceDefinitions?
u
I guess what is the ground truth of alpha/blank/certified?
u
because this standard is centrally enforced managed, I’m having trouble thinking about how it would be displayed in the app itself
u
I think the ground truth should be blank
u
alpha/certified are modifiers we publish to give context imo
u
sorry by ground truth
u
I meant default value not ground truth
u
I mean how/where the status of connectors is managed
u
right
u
Like should we add it to SourceDefinitoin and read it from there
u
and `master`’s config files are used to determine certification
u
That sounds good actually.
u
Certainly better than having an endpoint to manage this stuff
u
actually, there’s one problem with it
u
if you update from an alpha to a certified version, it won’t update your instance
u
hmm
u
it’s probably tied to a specific version though
u
oh but if you update it’s only through docker?
u
not the config files on master
u
I don’t think it makes sense to put it in the spec
u
since we’re the only people that can make it airbyte certified
u
I guess I’ll just add a separate file where we’ll track this.
u
Or we could remove the certification from badging and purely handle it in documentation
u
And manually label on the dashboard doc page
u
That might be the easiest at first
u
Least lockin too
u
why not in the spec?
u
^because we don’t control specs of connectors out in the wild
u
yeah
u
if someone uses a 3rd party docker image it should never say it’s airbyte certified within our UI
u
huh. fair.
u
so i guess we are saying we would want to be able to certify connectors we don't control?
u
mm no
u
I think we’re just saying that we want to control certification.
u
I suppose we could certify external ones if we wanted but that definitely isn’t a priority
u
it feels like we need a new “table” in our configs then
u
linking version to certification status
u
Yeah
u
We can also use a json file in master for the UI too. It could pull that as an “api” to get the current list
u
at least to tide us over
u
I’d like to limit table creation as much as possible so we don’t have to do db migrations
u
I imagine our tiers/certification will change over time
u
I think for now I’ll just remove the certification from badging and purely handle it in documentation
u
tu
u
And we can add that on later when it gets solidified more
u
to follow up
4 Views
Open in Slack
PreviousNext
Powered by