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

<https://github.com/pulumiverse/pulumi-sentry/commit/45b330553e04f13d128f5378a449b4670a586cf1#diff-a9f139b9a64998c7798981a1858c865a88ddfa6ec8d384027ee68139313a7cf2R15|https://github.com/pulumiverse/pulumi-sentry/commit/45b330553e04f13d128f5378a449b4670a586cf1#diff-a9f139b9a64998c779898[…]8d384027ee68139313a7cf2R15>

Ah, but not on `main` branch. Best not to release from a branch.

Also, don’t forget to document that this provider then requires Pulumi 3.53.3 for this download url to work.

Previously we made alpha releases from the PR branch. Since testing the download url requires a release it is going to be very slow going if we need to make a PR for each commit

With this github support in place in 3.53.3, no user should get the error anymore that you mention in the `Installing` section of your readme.

There is a bug where the plugin download url detection does not work if you use a yarn workspace so that the plugin module is located in a node_modules folder in a parent rather than in the working directory. I was going to see if this new plugin downloader has fixed that but i have not had the chance yet

I doubt it: <https://github.com/pulumi/pulumi/issues/8865#issuecomment-1172930983>

I am unable to reproduce the issue so perhaps it is fixed by having the plugindownloadurl in the provider actually work. :shrug:

I got a collaboration for the project now, do you still want me to tag you as well <@UK4HNFLCB>? :slightly_smiling_face:

No, I suggest you create a `CODEOWNERS` file in the repo and configure it as you see fit. If possible, add me for review if github actions are changed. I would like to work towards a consistent automated test &amp; release process for all providers.
<https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners>

Any chance we could get something like squash PR merges for the repo?

<@U02PYNXS6P9> constant debate between people on this. There is only a branch protection on `main`, so when the work in a branch/PR is done, you can rewrite your history on the branch *before* merge by running `git rebase -i HEAD~3` . Change the `3` to the nr of commits you want to go back in the history of your branch. After rewriting, do a force push. I hope this is a good middle-ground for you.