When we generate a new .NET project today with pulumi new, we target .NET 3.1:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    ...
    <TargetFramework>netcoreapp3.1</TargetFramework>
    ...
</Project>

But with .NET 3.1 a couple of versions behind now (6 is currently "recommended"), it's easy to run into problems if you're on a more recent version -- for example, I'm on 6, which was the default when I brew installed a few days ago:

$ pulumi up
...

Diagnostics:
  pulumi:pulumi:Stack (registry-867-dev):
    It was not possible to find any compatible framework version
    The framework 'Microsoft.NETCore.App', version '3.1.0' (x64) was not found.
      - The following frameworks were found:
          6.0.3 at [/usr/local/Cellar/dotnet/6.0.103/libexec/shared/Microsoft.NETCore.App]

From https://docs.microsoft.com/en-us/nuget/create-packages/multiple-target-frameworks-project-file, it appears we may be able to support multiple versions of .NET:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    ...
    <TargetFrameworks>netcoreapp3.1;net5.0;net6.0</TargetFrameworks>
    ...
</Project>

But when I try this with pulumi up, while dotnet build -nologo . succeeds, the preview process fails with the following:

Diagnostics:
  pulumi:pulumi:Stack (registry-867-dev):
    Unable to run your project
    Your project targets multiple frameworks. Specify which framework to run using '--framework'.

It'd be great if we could figure out how to support this, as it wasn't immediately clear to me (as a .NET novice) how to get around it.

We need to ensure that any testing errors are reported to slack

We seem to be using "@types/node": "^8.0.27" in our other examples, but I'm not sure that's the right version. @lukehoban, should we be using something like ^6.0? There doesn't appear to be a 6.10 version of https://www.npmjs.com/package/@types/node

What happened?

Understandably azure-native provider can be large but these timings are suspiciously high. I cannot reproduce such slowdown locally. Historical data indicates the slowdown is in "pulumi new" phase so possibly related to npm install and similar. Perhaps the downloads are slower in the CI environment? There was also a significant regression circa Sept 2021 for javascript.

TestTemplates/azure-javascript (15m49.79s)
TestTemplates/azure-python (14m48.17s)
TestTemplates/azure-typescript (20m0.01s)

Steps to reproduce

Look at CI timings.

Expected Behavior

Template tests take under 10 min in GitHub actions.

Actual Behavior

Template tests take 20-30 min in GitHub actions.

Versions used

No response

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

  linode:index:Instance (my-instance):
    error: 1 error occurred:
    	* Error creating a Linode Instance: [400] Account Limit reached. Please open a support ticket.

https://github.com/pulumi/templates/runs/2924350224?check_suite_focus=true

Steps to reproduce

This issue happens periodically in Run Template Tests Against Latest CLI + Dev CLI .

With the 2.0 release, we'll need to update all node, python, Go and dotnet dependencies for the 2.0 release.

All packages will get a major version bump, so we probably need to automate this.

We also need to make sure all deprecated package management systems have been removed, such as Gopkg

It seems, that the template "azure-javascript" does not exist anymore. I get an error in the webinterface and also on the CLI:

error: template 'azure-javascript' not found

Node 10+ has broad support for ES2018 -- we should update the TS templates to target it.

What happened?

With 20m timeouts introduced:

❌ TestTemplates/java-gradle (20m0s)
  Error:     template_test.go:99: Starting test run for "java-gradle"
  Error:     testing_utils_test.go:25: java-gradle timed out after 20m0s

Disabling testing this template until we can investigate. I suspect this has to do with gradle not being installed properly by default on the windows-latest runner (unlike ubuntu-latest), but there might be an issue with improper termination being masked by this. When gradle is not detected or is the wrong version, java provider should error out with an appropriate message, not hang.

Also failed to reproduce locally on a Windows VM in Azure, given Gradle is installed, the template works as expected.

Steps to reproduce

Enable java-gradle testing in CI.

Expected Behavior

CI fails with an exception or succeeds.

Actual Behavior

CI hangs.

Versions used

No response

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

For symmetry with how other languages work, I believe we ought to be running dotnet restore to install packages during template creation. E.g., like we do with Node.js and NPM.

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

We now (pulumi/pulumi#7764, pulumi/pulumi#8655) support the use of ECMAScript modules as Pulumi entrypoints. We support this natively in JavaScript and in pre-compiled TypeScript, and via some additional custom flags (using experimental Node.js loader features) for on-the-fly-compiler TypeScript.

This also enables the use of await at top level in Pulumi programs as in pulumi/pulumi#5161 (comment).

At some point, we may want our templates to make this the default for all new projects. I don't think we can do that yet for TypeScript because the features we depend on our experimental, and have in practice seen breaking changes, so this would risk exposing users to breaking changes in Node.js in the future. Given that, I'm inclined to also leave JavaScript templates as is for now, so that JavaScript and TypeScript are consistent by default.

Once these Node.js features are sufficiently stable though, we can revisit this.

Follow up on #287 and ensure we test YAML templates for regressions.

These were disabled due to broken GOPATH - we need to ensure these are tested like the rest of the templates

• go
• javascript
• python
• typescript
• aws-go
• aws-javascript
• aws-python
• aws-typescript
• azure-go
• azure-javascript
• azure-python
• azure-typescript
• gcp-go
• gcp-javascript
• gcp-python
• gcp-typescript
• openstack-go
• openstack-javascript
• openstack-python
• openstack-typescript
• kubernetes-javascript (#36)
• kubernetes-typescript (#33)
• openstack-typescript
• hello-aws-javascript

Would be nice to have a javascript-aws, typescript-aws and python-aws templates which include dependencies on AWS packages to keep Getting Started steps to a minimum.

It would be nice to automatically (or after a prompt?) run npm install as part of pulumi new so that the new project is in a more complete state. We likely would need pulumi new to be able to identify the runtime being used in the template or have templates specify a script to run on installation?

Beta feedback:

Generated package.json from template gives VS Code warning "Missing property "version"."

This also produces an npm warning on install.

related: #114

The version of both the pulumi and the providers that we're referencing is pretty out of date. It hasn't been updated since 2.0. Noticed this today when doing a pass over the generated go examples using pulumi new go-aws and seeing some missing types in my autocomplete due to the stale version that is brought in.

We should ideally use the latest released NPM version, not ^0.11.0 in our package.json for JavaScript/TypeScript templates.

Including auto-location and (if implemented) auto-naming

The various language pages have details about how the runtimes work and available configuration options. The templates should include a link to these pages in the project yaml file to make them more discoverable.

For example, for the aws-python template (https://github.com/pulumi/templates/blob/master/aws-python/Pulumi.yaml):

name: ${PROJECT}
description: ${DESCRIPTION}
# See https://www.pulumi.com/docs/intro/languages/python/ for more details and configuration options.
runtime: python 
template:
  description: A minimal AWS Python Pulumi program
  important: true
  config:
    aws:region:
      description: The AWS region to deploy into
      default: us-east-1

Some Python users prefer the Poetry packaging system to virtual environments. We should consider adding templates to pulumi new that help users successfully configure a Pulumi project using Poetry.

Installing template then following its instructions reports this:

ERROR: pulumi-kubernetes 1.6.0 has requirement pulumi<2.0.0,>=1.11.0, but you'll have pulumi 2.0.0 which is incompatible.

And then pulumi up fails with:

pkg_resources.ContextualVersionConflict: (pulumi 2.0.0 (/Users/lukehoban/dd/pulumidemos/iac-workshop-2/app/empty/venv/lib/python3.7/site-packages), Requirement.parse('pulumi<2.0.0,>=1.11.0'), {'pulumi-kubernetes'})

Our Getting Started guide for Python suggests using Pipenv, but our default python template leaves a requirements.txt and the instructions recommend using pip3 directly. We should reconcile these in one direction or another.

We filter out all non-TS/JS/Python templates by default. After Go and .NET are GA, we should probably add those to the default set of major cloud templates we show by default.

Ensure the Python templates work with the latest bits and bump versions in requirements.txt as needed.

When using pulumi new aws-typescript (for example), the user is prompted for a project name which is used in Pulumi.yaml. However, the same name is not used in the name field of the package.json file - something I believe we should reconsider.

• Refer to the latest versions of NuGet packages
• Use ${PROJECT} in project file names
• Use .NET Core 3.1
• Change to Stack-based API (Deployment.RunAsyc<MyStack>)

The tests in this repo use integration.ProgramTest, but because of the current behavior of integration.ProgramTest installing dependencies for the test project, the tests would not have caught pulumi/pulumi#7807. These tests are using pulumi new to create the project and dependencies should be installed as part of that. The tests should not be doing any further preparation, to ensure the project is ready with only the preparation done by pulumi new.

Once there is an integration.ProgramTestOptions option to skip preparation (see pulumi/pulumi#7820) we should fix up the tests in this repo to use it.

Depends on pulumi/pulumi#7820

For the aws-typescript template, we import of the awsx package to help advertise it:

Do we want to do the same for the kubernetes-typescript template also? I.e.

import * as kx from "@pulumi/kubernetesx";

@leezen I think always adding the main entry in package.json on pulumi new will help avoiding such issues from the beginning. Took me some time to figure this out the first time I've seen this.

Originally posted by @Dominik-K in pulumi/pulumi-aws#933 (comment)

We need a mechanism to keep our go.mod files up to date as we release new versions of pulumi/pulumi and providers.

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

.NET 6 is the current LTS version. We should switch our templates to .NET 6 and use the latest C# features like top-level statements to make the program as nice and as simple as possible.

Update GCP-related templates to use 2.x version of GCP provider, which has all the latest and greatest services

Here:

cloud.HttpEndpoint got renamed to cloud.API.

The tests in this repo are failing fairly regularly (though inconsistently). For example https://github.com/pulumi/templates/commit/32b6ad11c3900f270f3409d125a4a60103fb3261/checks.

Update Python templates to use classes rather than dicts for nested inputs/outputs.

Part of pulumi/pulumi#3771.

We should consider adding IDE workspace settings files to our Python templates that have the path to the Python interpreter inside the virtual environment already configured.

For VS Code, this would be a .vscode/settings.json file that looks like:

{
    "python.pythonPath": "${workspaceFolder}/venv/bin/python"
}

This way, users won't have to manually select the interpreter path in VS Code to get the nice intellisense features.

As a bonus, for VS Code, we should also consider including a .vscode/extensions.json file, with recommended extensions for the project (e.g. the Python extension and Pylance).

Need to look into whether there are equivalent settings files we could include for PyCharm.

One minor hiccup is if you specify -g (--generate-only) to pulumi new, a virtual environment is not created, and there's currently no way to conditionally avoid emitting template files, so the files would be emitted configured to use a venv directory that doesn't exist. But I suspect it'd still be a net improvement to include these files, so that the default experience is better when using these two popular IDEs out-of-the-box. Users who aren't using the default virtual environment support or are using other IDEs can simply delete or ignore these files.

What happened?

Something is off with azure template checks.

When merging fix for java templates (not tested yet, TBD) #276

We noticed that CI failed indicating azure templates checks did not succeed.

https://github.com/pulumi/templates/runs/6295416238?check_suite_focus=true#step:18:741

Steps to reproduce

See https://github.com/pulumi/templates/runs/6295416238?check_suite_focus=true#step:18:741

Expected Behavior

CI passing on PRs

Actual Behavior

CI failing

Versions used

No response

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

I'm seeing the following warning after running pulumi new aws-csharp

Program.cs(17,20): warning CS8619: Nullability of reference types in value of type 'Dictionary<string, object>' doesn't match target type 'IDictionary<string, object?>'. [/Users/justin/Desktop/2020/01/29/nodemod/nodemodprog/Infra.csproj]

It looks like the issue is due to this in the template:

return new Dictionary<string, object>
{
    { "bucketName", bucket.Id },
};

According to the warning, it should be:

-return new Dictionary<string, object>
+return new Dictionary<string, object?>

Would be good to do a pass over all the other C# templates as well.

Full output:

$ pulumi new aws-csharp
This command will walk you through creating a new Pulumi project.

Enter a value or leave blank to accept the (default), and press <ENTER>.
Press ^C at any time to quit.

project name: (nodemodprog) 
project description: (A minimal AWS C# Pulumi program) 
Created project 'nodemodprog'

Please enter your desired stack name.
To create a stack in an organization, use the format <org-name>/<stack-name> (e.g. `acmecorp/dev`).
stack name: (dev) 
Created stack 'dev'

aws:region: The AWS region to deploy into: (us-east-1) 
Saved config

Installing dependencies...

running 'dotnet build -nologo .'
  Restore completed in 2.66 sec for /Users/justin/Desktop/2020/01/29/nodemod/nodemodprog/Infra.csproj.

Program.cs(17,20): warning CS8619: Nullability of reference types in value of type 'Dictionary<string, object>' doesn't match target type 'IDictionary<string, object?>'. [/Users/justin/Desktop/2020/01/29/nodemod/nodemodprog/Infra.csproj]

  Infra -> /Users/justin/Desktop/2020/01/29/nodemod/nodemodprog/bin/Debug/netcoreapp3.0/Infra.dll


Build succeeded.


Program.cs(17,20): warning CS8619: Nullability of reference types in value of type 'Dictionary<string, object>' doesn't match target type 'IDictionary<string, object?>'. [/Users/justin/Desktop/2020/01/29/nodemod/nodemodprog/Infra.csproj]
    1 Warning(s)
    0 Error(s)


Time Elapsed 00:00:04.91

'dotnet build -nologo .' completed successfully
Finished installing dependencies

Your new project is ready to go! ✨

To perform an initial deployment, run 'pulumi up'

In addition to templates that can be used as empty starting points, we should consider a "hello world" template which works well as a first app for first-time-users to deploy to get started quickly.

Ideally this would meet the following goals:

1. Be simple
2. Use real cloud resources
3. Use only free (or very low cost) resources
4. Require the bare minimum of external configuration
5. Have an addressable endpoint that "does something" as an output
6. Be quick to deploy, destroy
7. Highlight a couple unique Pulumi capabilities (components, loops/functions, etc.)

The .NET project templates for specific providers currently only depend on the provider NuGet package, e.g. aws-csharp's .csproj only has a single package reference:

  <ItemGroup>
    <PackageReference Include="Pulumi.Aws" Version="4.*" />
  </ItemGroup>

When the project's dependencies are restored, it will get the latest Pulumi.Aws. But the transitive dependencies always resolve to the lowest package that fits. Pulumi.Aws 4.29.0 has a dependency on Pulumi >= 3.18.0, which means Pulumi 3.18.0 will be installed (the lowest version that matches the requirements) rather than the latest version of Pulumi, 3.18.1. This is not ideal as 3.18.0 has a regression that is fixed in 3.18.1.

To address this, we can include a package reference to Pulumi in our template projects.

  <ItemGroup>
    <PackageReference Include="Pulumi" Version="3.*" />
    <PackageReference Include="Pulumi.Aws" Version="4.*" />
  </ItemGroup>

With this, when restoring the project's dependencies, it will resolve the latest 3.x version of Pulumi, 3.18.1.