pulumiverse / .github Goto Github PK

I currently maintain the pulumi-hcp provider through my employer, but we will unfortunately not be able to continue maintaining it. As such, we would like to donate it to the Pulumiverse organization to ensure it remains available for the broader Pulumi community.

I currently maintain the pulumi-buildkite provider through my employer, but we will unfortunately not be able to continue maintaining it. As such, we would like to donate it to the Pulumiverse organization to ensure it remains available for the broader Pulumi community.

This is a placeholder issue for the initial organisation setup. Here we will discuss how repositories can be onboarded and how new maintainers can be added

I want to create a pulumi provider for Sentry.io based on this terraform provider: https://registry.terraform.io/providers/jianyuan/sentry/latest/docs.

@ringods please transfer these providers back to me, @jaxxstorm.

I no longer want them to be a part of the Pulumiverse.

The current publish keys are linked to @ringods's user account which means all publishes appear to be from him

This has a few problem implications, not least that it violates the bus factor.

My suggestion would be to create a pulumiverse-bot user for each of the package registries and place the details in 1password so they can be shared

now that the tf plugin bridge is working I'd like to contribute my bridge to vercel
this is following up on pulumi/pulumi#7615

my repo is here https://github.com/omercnet/pulumi-vercel and is still a work in progress but should be ready for publication later this week

If it's interesting to the community, I have published a small, self-contained python library and command line tool that can directly encrypt and decrypt secrets in a way that is compatible with the passphrase provider.

This package was originally developed as part of a solution to work around a limitation of the current pulumi release--there is currently no easy way to get/set nonsecret config properties or stack deployment outputs without knowing the correct passphrase, even if the passphrase is irrelevant for that task. By directly implementing a private version of pulumi config and pulumi stack output it is possible to defer use of the passphrase until it is needed, and allow working with encrypted inputs/outputs as well as nonsecret inputs and outputs, without knowledge of the passphrase. It is also helpful for automating construction of stack config files before a stack exists.

PyPi details here: https://pypi.org/project/pulumi-crypto/.
GitHub repo here: https://github.com/sammck/pulumi-crypto.

Use the Terraform bridge to publish the Terraform Provider for Pact as a Pulumi provider and publish it on the Pulumi Registry.

References:

• https://docs.pact.io/pact_broker/terraform_provider
• https://registry.terraform.io/providers/pactflow/pact/latest
• https://github.com/pactflow/terraform-provider-pact

We need to standardize on a specific OpenSource license, preferrably for all contributions (code, documentation, ...)

@aaronkao can you check with your legal team? I suppose we are safe if we use the same license as for Pulumi itself, which is the Apache 2 License.

There are still references to Pulumi X in it.

Build a new provider for the VMware ESXi hypervisor to provision VMs directly on an ESXi hypervisor without a need for vCenter or vShpere.

In case we want to build a home lab on-prem infrastructure using ESXi, to provision it with Pulumi we need to install rather vSphere or vCenter as the current provider by vSphere doesn't support the ESXi management directly.

We would like to emphasize that the conventional commits are guidelines and are not intended to do be blockers. This may include rewording, and maybe reducing the "importance" of the header.

We would also like to introduce the topic of squash merges, with comments on when to consider using them and when not to bother. If this is introduced as the main topic in a section on "Commits & PRs", the conventional commits section might be made a 2nd topic in that section.

This is a follow-on from PR #14 .

👋

Do we wanna use the special .github repository?

In that case, do we still wanna use this repository to maintain the files? E.g. CONTRIBUTING.md could be stored in this repository, and pull requests opened here, but we could have a Github Workflow that updates the files (less overhead).

Thoughts?

I want to provide a Pulumi Provider based on the PGSSoft/terraform-provider-mssql Terraform provider.

Docs: https://registry.terraform.io/providers/PGSSoft/mssql/latest/docs

Can someone create a new repo for it in Pulumiverse and add me as a contributor? 😃

I want to create a pulumi provider for StatusCake based on this terraform provider: https://registry.terraform.io/providers/StatusCakeDev/statuscake/latest/docs.

Hi team.

Folks from pulumi team advised me here to consider migrating my DataStax Astra provider into pulumiverse. It is possible to do? And what should I do for this?

Link to the provider

Ask Geoffrey Huntley to migrate/contribute the awesome list to the community:

https://github.com/ghuntley/awesome-pulumi

Status: @stack72 will introduce @ringods to Geoffrey