Dagger orb (CircleCI's lego brick) here: https://github.com/logicalhq/dagger-orb
Not yet listed as a public orb in the Orb Registry: https://circleci.com/developer/orbs

@gcoguiec It looks like your dagger-orb repo isn't up anymore. Would you be willing to donate the code to Dagger to maintain?

Have a CircleCI example going up in PR right now. With more complex example (caching) to follow. #2842

@nicolas-goudry Did you try it already? If yes, what have been your experiences?
I'm evaluating different CI/CD Frameworks to run on GitLab CI Kubernetes Executor so input would be helpful, thanks.

@maudeFW Sorry for replying so late, I didn’t have time to look into it yet…

GitLab example getting better and better here: https://docs.dagger.io/1201/ci-environment

Any updated doc about integrating/migrating from gitlab-CI to dagger ?

hey @Aboitier! Dagger won't replace your CI runner, but we have several people in our Discord using both gitlab hosted and self-hosted runners with success. If you have some questions about it, would love to chat about it more in our Discord server 🙏

I'll third for jenkins

4th for jenkins

Me to

Me too

Jenkins example and video here: https://docs.dagger.io/1201/ci-environment

Chiming in for ADO as well, as I've seen more and more clients using those.

Please make Azure Devops a reality!!!

This would be a game changer for Azure DevOps Pipelines.

@gerhard can you tell us the probability that you will integrate dagger with azure devops? :)

@tadavid-cae @Pre-Z What would ADO support look like?

Would there need to be an extension or just an Azure Pipelines YAML example?

And by extension, Jenkins X that uses Tekton inside.

We have Tekton here :) https://docs.dagger.io/1201/ci-environment

This one is important for my organization. Also, TeamCity supports inheritance, while Jenkins and others do not.

Example: root project (with secrets to access git and triggers for pull request) has a child of build artifacts, which builds binaries on various platforms, and this has test children pipelines for integration tests and unit tests that consume the artifacts, so root > build > {unit_tests, integration_tests}.

, so for example, integration test pipeline and unit test pipeline could be dependent on a parent build pipeline that is executed prior and stores executable artifacts, and this in term is inherited from a parent that fetches the code and has secrets used to access the gitrepo, as well as triggers for pull requests, and so on.

@darkn3rd if you have something that could help start a simple Team City example (or links), that would be great. Also PRs accepted ;)

Inspiration: https://docs.dagger.io/1201/ci-environment

Info about TeamCity integration has been added to the docs: https://docs.dagger.io/getting-started/ci-integrations/teamcity

Argo is mostly a CD platform, isn't it? It already relies on pre-existing CI solutions like GA, Circle, Tekton, etc for the CI part. Not sure what could be done in Dagger as an Argo direct integration 🤔

@marcosnils I'm not sure if that's what @eddumelendez meant, but we use Argo Workflows to create our CI pipelines. It could be useful to have Dagger integrated with it so we could test them locally. Argo Workflows + Argo Events + Argo CD is basically a CI/CD platform by itself. For reference: https://argoproj.github.io/argo-workflows/

got it, thx! Wasn't aware about workflows. It looks like a potential opportunity for dagger as well.

Jenkins example and video here: https://docs.dagger.io/1201/ci-environment

Concourse CI

Concourse would be amazing, seeing as it's modern, built for CD, able to handle extreme complexity and is not tied to a provider.

same to me

@gerhard I created a simple dagger pipe for bitbucket pipelines just like dagger-for-github
But ended up with following error

{"level":"error","error":"exit status 125","output":"docker: Error response from daemon: authorization denied by plugin pipelines: --privileged=true is not allowed.\nSee 'docker run --help'.\n","time":"2022-04-03T07:20:49Z","time":"2022-04-03T07:20:49Z","caller":"/home/runner/work/dagger/dagger/util/buildkitd/buildkitd.go:210","message":"unable to start buildkitd"}

since bitbucket pipelines doesn't allow container(pipe in this case) to be run in --privileged mode, which is a requirement for buildkit. Github actions also doesn't allow privileged mode by default, so wondering how it was solved for github actions. I would be happy to receive your feedback regarding the same.

Ended up with the same error that I couldn't get around. I may be a bit off, but I think it may be possible to get it running once this is fixed.

https://jira.atlassian.com/browse/BCLOUD-17590

Bitbucket Pipeline docs say they do not allow privileged mode.
https://support.atlassian.com/bitbucket-cloud/docs/run-docker-commands-in-bitbucket-pipelines/

A potential workaround would be to use Bitbucket Runners and self-host the build machine, at which point you have total control over it, though you do lose the ephemeral aspect. I'm going to try that for some of our projects.

Seems to still not be possible with Atlassian-hosted runners at the moment, even though BuildKit support is available in preview, since --privileged=true is still not supported
https://jira.atlassian.com/browse/BCLOUD-13420
and we currently run BuildKit as --privileged in Dagger.
https://github.com/dagger/dagger/blob/main/util/buildkitd/buildkitd.go#L238

Seems like self-hosted runners with dind or a DOCKER_HOST over ssh would be needed.

image: atlassian/default-image:3

pipelines:
  default:
     - step:
         name: 'Install and run Dagger'
         script:
           - cd /usr/local
           - wget -O - https://dl.dagger.io/dagger/install.sh | sh
           - cd -
           - dagger version
           - dagger project update
           - DOCKER_BUILDKIT=1 dagger do hello --log-format plain
         services:
          - docker

Jenkins and Tekton here :)
https://docs.dagger.io/1201/ci-environment

A basic AWS Codebuild was possible using a build task configured with the aws/codebuild/standard:5.0 image and the following Buildspec, pwd, ls are still in there to see the folders/structure in the logs:

version: 0.2

phases:
  pre_build:
    commands:
      - pwd
      - curl -L https://dl.dagger.io/dagger/install.sh | sh
      - ls
      - ./bin/dagger version
  build:
    commands:
       - ./bin/dagger project init
       - ./bin/dagger project update 
       - ./bin/dagger do build

Yes please, their CLI is cool but the integration would be really helpful

#1677 (reply in thread)

#1677 (reply in thread)

#1677 (reply in thread)

I am interested in Spinnaker CD pipelines, which are reflected in JSON, and can be downloaded. They can also be uploaded with changes to create new pipelines. There's a CLI tool that I use to manage the pipelines https://spinnaker.io/docs/guides/spin/pipeline/

Sounds like an ideal use for Dagger. You could consume/generate the Spinnaker JSON and invoke the CLI. Let me know if you'd like to set up a POC/pilot to get that going :)

I second that, having one more example with GCP Cloud Build and AWS Code Build would complete the collection of all usual CI plus all the hyperscaller's. one. This would create a nice "Wow" factor for any MSP that are revewing dagger since it would demonstrate all the CI of all their clients can leverage dagger and further demonstrate the joy dagger brings to the table.

It's not hard getting it working in Codefresh but it requires granting root privileges to the job. Currently only the hybrid option where you run the Codefresh workload on your own k8s cluster will allow this.