Define another user-agent than the Terraform provider's one

[scraly]

Hello!

It's mandatory for us to have a custom user-agent coming from our terraform pridged pulumi provider when API is called.

Is it possible to define a custom user-agent?

[danielrbradley]

There's a few appraoches that can be used for overriding user-agent strings and it depends on how the upstream provider is implemented as to which is best to use.

Our most common approach is by modifying the upstream code via a patch. A good example of this is pulumi-azure where the upstream terraform provider is checked out as a submodule in the upstream directory. The scripts/upstream.sh is used to manage additional patches which are written to the patches directory in the provider repository and applied to the upstream working directory during the build. This is still a little experimental and not yet fully documented, but is the most reliable approach we've found.

Here's an extract on how to create a first patch:

1. Create a git submodule in the upstream directory of your repository pointing to the git repository of the upstream terraform provider.
2. Ensure the upstream folder has a clean git state. You can run make upstream to do this.
3. Run ./scripts/upstream.sh checkout. This will check out a new branch in the upstream submodule.
4. In the submodule folder, make the changes you need. Add a file, remove a line, fix a bug.
5. Commit those changes. Please write a concise, descriptive commit message - this will become the name of your generated patch.
6. From the pulumi provider root, run ./scripts/upstream.sh check_in. This will generate the new patch file. It expects, by convention, to live in a folder called patches/.
7. Re-run make upstream to return the upstream submodule to its clean state, as per our first submodule concept - we always keep the upstream version tag checked out and clean.
8. Commit your new patch.
9. Now when you generate the provider with make tfgen, the provider will be generated against the patched submodule dependency.

Alternatively, there are some possible workarounds with Go to avoid adding patching:

1. Set the value of the variable on startup, if it's exposed.
2. If the upstream provider defines the user agent string as a module-level variable, then it can be set using Go build's ldflags.
3. Use a Go "shim" to add code within the upstream module which can access internal variables and set from there.

[danielrbradley]

So, @VenelinMartinov just mentioned that you also own the upstream provider, in that case I'd recommend making your own life easier and exposing the user agent variable so it can be set from your pulumi provider on startup!