Oh, I'd also be interested to know what provider you're bridging.

I’ll be honest, it’s been a pretty painful experience - not so much the core bridging experience, but everything on the edges - getting all the packages to compile, dealing with issues where things are hardcoded to the

pulumi

github org or a Pulumi S3 bucket, etc. This is exacerbated by the fact that a Pulumi plugin is a very involved thing (language SDKs, binaries, etc), so it’s not as simple as just getting the repo itself going. I’m currently trying to get the CI scripts to run - probably been doing this for the past 5-6 hours and still not done 😄

I’m trying to bridge the Frontegg provider. Here is the bridged repo: https://github.com/okera/pulumi-frontegg

So one example I’ve hit right now - I don’t really care about the language SDKs beyond Go, at least for now. But the

publish_sdk

step in the CI scripts publish all 4 of them, without really any way to limit it. And so now I need to figure out the PyPI package name and credentials and so on.

I’m happy to chat more in depth if it is helpful.

We do have a standard naming convention for our SDKs. It might need to be more explicit, but it's at least implied in the README: https://github.com/pulumi/pulumi-aws#installing

In the boilerplate, the README that will eventually become the provider's README at the end of the instructions is here: https://github.com/okera/pulumi-frontegg/blob/main/README-PROVIDER.md This is not necessarily most obvious thing, but I wanted to try to give a clean separation between the boilerplate instructions and the README content for the new provider itself.

As an example, it would be really convenient if rather than relying on every machien you want to dev this on to have dotnet/python/nodejs installed that you instead have a docker that can do this

(which is kind of what you do in the CI world, but not for the original package authoring)

A few other thoughts: 1. It’s not actually clear how to publish something that isn’t an official Pulumi package. Where should the packaged binaries go? How do I consume them for my Pulumi program (when CI is building them on GitHub)? 2. There’s not a ton of clarity about what needs to be checked into the repo and what doesn’t. As far as I can gather, the output of

make build_sdks

should be checked in, but it’s not called out. 3. Versioning is only tangentially referred to, and it’s not really 100% clear how to get versioning like what the other packages have and how to maintain it.

1. packaged binaries go in GitHub releases now, and you just need to update your `pluginDownloadUrl`: https://github.com/jaxxstorm/pulumi-scaleway/blob/master/provider/resources.go#L85 2. yes we should fix that, the SDKs do need to be checked in, then published to providers 3. would love some elaboration there, are you talking versioning across the sdks? or bumping providers?

This is exacerbated by the fact that a Pulumi plugin is a very involved

thing (language SDKs, binaries, etc), so it’s not as simple as just getting the repo itself going.

I’m currently trying to get the CI scripts to run - probably been doing this for the past 5-6 hours and still not done

I totally agree here, it's hard 😞 part of the issue is the multiple languages as you say, and honestly we could do a better job of documenting this

I think the last missing piece is the GitHub releases part - my repo doesn't seem to have a release yet even though I ran the CI

@billowy-army-68599 is there an explanation of the variety of secrets needed for the CI actions? For example, the

tag_sdk

step is failing, and I have a feeling it needs

GITHUB_TOKEN

to be defined, but not sure what that needs to be set to, and I can’t find any docs to this effect. If there’s an explanation somewhere of what these all should be, it would be very helpful.

@bored-table-20691 I'm happy to jump on a call and get you over the line if that helps later this week?

The token prrrrrrobably just needs repo read/write, unless you're using it to comment on issues or things like that.

Specifically, it’s this task that fails:

tag_sdk:
    name: tag_sdk
    needs: publish_sdk
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Repo
      uses: actions/checkout@v2
    - name: Install pulumictl
      uses: jaxxstorm/action-install-gh-release@v1.2.0
      with:
        repo: pulumi/pulumictl
    - name: Add SDK version tag
      run: git tag sdk/$(pulumictl get version --language generic) && git push origin
        sdk/$(pulumictl get version --language generic)

From reading the GitHub forums, seems like it is a permission issue with the token

i.e. no way to connect it to the org

How required is the tag_sdk task?

notice the github releases url here: https://github.com/jaxxstorm/pulumi-scaleway/blob/master/provider/resources.go#L86

This is another one that I ended up disabling as I wasn’t sure if it was needed or what token was needed for it): https://github.com/okera/pulumi-frontegg/blob/main/.github/workflows/release.yml#L104