Verify Pulumi Provider Release Action

Verify that a published Pulumi provider is usable from its SDK for a particular platform.

This action performs a simple preview operation of a program having installed the specified SDK version. This can be executed in Linux, Mac and Windows environments to ensure cross-platform builds work correctly.

Usage

- uses: pulumi/verify-provider-release@v1
  with:
    # The runtime to test against. One of `nodejs`, `python`, `dotnet` or `go`.
    runtime: 'nodejs'
    # Path to a Pulumi program to use for the test.
    directory: examples/simple-nodejs
    # The name of the provider (excluding the publisher prefix)
    provider: xyz
    # The version of the provider to be tested.
    providerVersion: '1.0.0'
    # The version of the package to be tested. Defaults to `providerVersion`
    # if not set. This must be set for Go because its versions are always a
    # different format to the provider's.
    packageVersion: '1.0.0'
    # Template to generate the go module to be used.
    # Available template fields: `{publisher}`, `{provider}`, `{moduleVersionSuffix}`
    # {moduleVersionSuffix} is calculated from the provider version e.g. "/v2"
    # Defaults to: `github.com/{publisher}/pulumi-{provider}/sdk{moduleVersionSuffix}`
    goModuleTemplate: 'github.com/{publisher}/pulumi-{provider}/sdk{moduleVersionSuffix}'

Language-Specific Details

Python

1. When testing prereleases, you'll need to set the packageVersion because it will always be a different format to the provider's version.

2. The Pulumi.yaml runtime must set the virtualenv option to venv:

   runtime:
     name: python
     options:
       virtualenv: venv

Development Setup

1. 🛠️ Install the dependencies

   npm install

2. 🏗️ Package the TypeScript for distribution

   npm run bundle

3. ✅ Run the tests

   $ npm test
   
   PASS  ./index.test.js
     ✓ throws invalid number (3ms)
     ✓ wait 500 ms (504ms)
     ✓ test runs (95ms)
   
   ...

Publishing a New Release

1. Create a GitHub release specifying a new tag (e.g. v1.2.3) & generating release notes. This helps to communicate improvements and keep a record of significant changes. We MUST follow semantic versioning - only major versions can have breaking changes.

2. Fast-forward the major version branch (e.g. v1) to the latest commit on the main branch and push it. This is used to let our projects pin to just the major versions and automatically recieve non-breaking changes.