No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

maybe this is an area where pulumi would want to go? I could see another type of program that would represent the buids, triggers, etc :slightly_smiling_face:

Not sure what CI system you’re using, but <https://www.pulumi.com/docs/guides/continuous-delivery/> might have some useful info for you

I would see a pulumi program that represent a build sequence

there is THE program for this already: <https://buildbot.net/>

<@UG53R9UJC> that’s in python language right? it looks nice

yes it is in python and  is oldest player in this market

Another possibility is implementing a pulumi provider for whatever CI backend so that you could manage it with pulumi. If there’s an existing terraform provider, it’s fairly easy to generate a pulumi one from that

I just think that Pulumi covering CI/CD is the next logical step, I have my stacks ready to be automated.. why not have a pulumi program that takes trigger A, update pulumi stack etc

basically I want to avoid writting yaml files, I would want to write my CI/CD sequence with TypeScript :joy:

I’m curious, what CI/CD does the pulumi team use internally? <@UE1LN7A22>

Currently a combination of TravisCI and GitHub actions. But I agree with your points :smile:

I have the following pulumi “programs” right now:
- identity (AWS Org, Accounts, Users, base IAM)
- infra (EKS cluster, ECR, etc)
- auth (authentication + permissioning layer)
- apps (service and application to be run on the cluster)

a “ci” pulumi program would be awesome sauce, since I could reference the other stacks and trigger updates “pulumi up” based on conditions (like what trigger do I have)

this would be soooo awesome to write in a normal language

in over 7 years of workin in IT, my most miserable moments have been “configuring the goddamn CI”

by CI sequence, i guess you mean running all the stacks one after the other?

I mean, like the CI we know

1. trigger happens (git or manual)
2. depending on condition (what branch, what trigger) run whatever you need, including “pulumi up” on pulumi programs that needs to be updated

Joe Duffy pointed me to: <https://atomist.com>

but the paradigm they use.. is very very different from what we are used to.. anyway, it’s worth having a look