#commit statuses

1 messages · Page 1 of 1 (latest)

hybrid spindle
#

hey, just trying to wrap my head around where you guys are heading with this

are these integrations with GitHub being built directly into the CLI (e.g. "each +check is a commit status"), or is it logic that's encoded into dagger's CI modules?

how's it authenticating to github? specifically, will it be able to use the ${{ github.token }}, or does it need to be a GitHub App?

daring grove
#

it's a GitHub app - these are initiated by Cloud itself, driven by GitHub events, without GitHub actions involved anywhere. so no CLI integration

hybrid spindle
#

gotcha--thanks!

#

are you guys more focused on building features like this into cloud rather than the CLI for monetization purposes, or is there a technical limitation that keeps this kind of functionality out of the CLI?

#

I'd been imagining how sweet it would be if the CLI checked if GITHUB_ACTIONS == true (and so on for other CI runners) and then pushed data like this into the CI runner's platform directly

fallow vortex
#

@hybrid spindle generally we make those decisions from a product-design perspective. If it makes sense for a feature to be in the open-source engine, we add it there. If it only makes sense as part of a broader cloud service, then we do that. So far that system has worked well.

#

If you're running a whole cluster of engines, it doesn't really make sense to have each of those engines integrate directly with the Github API. Even assuming that's technically possible, it would be a nightmare to manage.

#

Re: technically possible: Github Actions is a very locked down platform, and integrations that you would assume are possible, often are not, because Github reserves it for first-party access only.

#

Example: artifacts upload for test reports

hybrid spindle
#

makes sense, thanks!

fallow vortex
#

The context for us doing this @hybrid spindle is not to integrate better with GHA - it's to replace GHA with a dagger-native stack that is 10x faster and simpler

hybrid spindle
#

yeah, a dagger-native stack that has engines pre-running with a persistent cache will be super nice.

I was just dazzled by the idea of this functionality being in the CLI for the same reason that that CLI dazzled me in the first place--the portability between environments.

that said, upon further consideration, it wouldn't really make sense to do it that way. only the CI orchestrator would know the source of the event that triggered the run, and so only the CI orchestrator would know where to push commit status results, annotations, etc.

fallow vortex
#

I promise that if it makes the user experience clearly better to move a feature into the CLI, we'll do it 🙂

fallow vortex
hybrid spindle
#

i'd be excited to be a beta tester of it for you guys, but i warn that i've only got my personal projects to do it with.

i've not yet been successful in convincing my particular set of corporate overloads to adopt dagger

#

related: I know @daring grove devised a system for bass-loop where you bring-your-own compute. are you guys planning to do something similar, or is dagger cloud providing the compute?

fallow vortex
#

Everybody wants self-hosted in theory, but when it comes to our commercial product, we only care about what people willing and able to pay us want 🙂

hybrid spindle
#

makes a ton of sense. as someone who's never worked in IaaS, let alone in a "startup" like dagger (even as awesome as it is), the prospect of paying for all that compute and hoping that someone will pay you to use it is frightening

#

though that's probably not the full picture--i imagine you already have customers that you expect to meet the demand, and that's the bit that i'm missing

#

what an exciting problem to solve, eh

fallow vortex
hybrid spindle
#

oh right the engines don't need to run constantly because they have the shared cache that you're working on

fallow vortex
#

Most compute providers let you persist machine storage even while the machine isn't running. So we can leverage that to persist cache while still not paying for idle compute

#

On top of that, yes being able to persist cache data in object storage services will help a lot - but that's still several months away, we don't want to wait that long before building a managed service

hybrid spindle
#

so i guess the only compute that you need to pay for is whatever is running cloud to receive events from e.g. GitHub, which is..relatively small

fallow vortex
hybrid spindle
#

guess that's just what happens when you start with a great product

fallow vortex
#

The issue with self-hosting is that it is a major upfront investment of engineering. That's the main risk actually - making the upfront investment, and committing to one specific self-hosting design, before demand is confirmed.