#I think I've got it.

1 messages · Page 1 of 1 (latest)

fallen zenith
#

Hi,

I just watched the "Get Started with Dagger Node.js SDK video and I now can see how we can possibly use Dagger for a problem that wasn't yet solved in our "dream platform".

So, I have two questions:

  1. In our future platform, the developers will be using Git for version control, of course. And, we think we could use Dagger for specific platform testing above and beyond normal app testing, like sniffing for evil code aka a trusted code process like making sure there are no database calls in loops or code doing exec calls that are 100% unnecessary. Is there a way to have this test code be local to the container Dagger fires up and far away from the dev's fingers?

  2. A bit less a subject for Dagger, but is there a known way to have Dagger code in a repository that is basically managed to a point by the platform, but where the dev can also get read only access? In other words, if the dev tries to mess with the Dagger code, the system will basically tell the dev they are doing something terribly wrong and to stop it? 😄 The idea being, the Dagger code is not their responsibility. We've come up with some ideas on this, as we have other "code" in the application repository we need to protect as "platform specific", but I was just wondering if this was possibly thought of and maybe even done before.

placid patio
#

In our future platform, the developers will be using Git for version control, of course. And, we think we could use Dagger for specific platform testing above and beyond normal app testing, like sniffing for evil code aka a trusted code process like making sure there are no database calls in loops or code doing exec calls that are 100% unnecessary. Is there a way to have this test code be local to the container Dagger fires up and far away from the dev's fingers?

Yes, there's multiple ways you can achieve this. Would you like to shift left this as much as possible like running it on the developer's machine as part of their daily test/build process? Or doing it in CI after a push is enough?

#

A bit less a subject for Dagger, but is there a known way to have Dagger code in a repository that is basically managed to a point by the platform, but where the dev can also get read only access? In other words, if the dev tries to mess with the Dagger code, the system will basically tell the dev they are doing something terribly wrong and to stop it? 😄 The idea being, the Dagger code is not their responsibility. We've come up with some ideas on this, as we have other "code" in the application repository we need to protect as "platform specific", but I was just wondering if this was possibly thought of and maybe even done before.

The benefit of Dagger is that since it's code, developers can just import it in their application as any other code library

#

so If your team has a pipeline to build / test a Java app for example. You can provide them a Dagger Java (or other language) functions that they can safely import in their pipelines which they won't be able to modify. The fact that Dagger handles pipelines as actual code is what it unlocks all these possibilities. LMK if that makes sense

#

cc @earnest zealot

fallen zenith
#

@placid patio

Would you like to shift left this as much as possible like running it on the developer's machine as part of their daily test/build process? Or doing it in CI after a push is enough?

Haha! Very good questions indeed.

We haven't discussed this yet in detail internally, but I'd very much like always to have as fast a feedback as possible for the dev. So yes, shift left as much as possible.

I'd imagine this kind of process.

  1. The dev wiil only be working remotely, on "in cluster" workspaces.
  2. They should be able to do practically anything they want (even try evil stuff) as this environment is "locked off" from anything "needed-for-the-system", so they can't get their fingers on anything to do bad stuff on, in other words 100% away from anything that could harm other tenants or the other production clusters in general.
  3. Before they can "promote" their work to the next level (i.e. from dev to staging)l, that is when it should "pass the litmus testing" to be considered promotable. However, the challenge is to have the user get this feedback at the point of committing.
#

developers can just import it in their application as any other code library
Of course! Duh. Ok. That answers my question. I was stuck in the perspective of our infra code, which wouldn't be packageable. And, yes in theory and in my mind up till now, the CI process should be standardized for everyone. Ok. Thanks for pulling me out of my incorrect perspective on this challenge. 😄

placid patio