<@U02J3T6A8LB> what is the order of steps to fix s...
# dotnet
l
@echoing-dinner-19531 what is the order of steps to fix something for dotnet code generation when the test needs to be activated here: https://github.com/pulumi/pulumi/blob/master/pkg/codegen/testing/test/sdk_driver.go#L353 while the fix is to be made in
pulumi/pulumi-dotnet
repo?
The issue I'm looking into is this one: https://github.com/pulumi/pulumi/issues/15874
e
Oh what confluence, I was just looking at property names. We're hopefully discussing it later today. I'll be getting a conformance test in place for this rather than relying on that old codegen test.
l
I want the hyphened property names work for crd2pulumi in the end. Hyphens already fail for cert-manager at the moment
e
ack, makes sense
l
@echoing-dinner-19531 was it discussed yesterday? If not, can you in short describe how to contribute best using a conformance test?
e
It wasn't all the time got taken up discussing some new cloud work. The conformance test code is at pkg/testing/pulumi-test-language. Write a new provider that uses kebab-case fields, and then write a test (pcl + go file) that checks those fields can be used. There's gonna be some design questions around how kebab-case fields should be projected to all the languages to support this though, so I don't expect it to be that small or quick.
l
@echoing-dinner-19531 given it is already covered for Go & Python in this PR, and probably JS/TS in another PR as well, I was thinking of matching the dotnet implementation.
e
You could change the Skip entry in pkg/codegen/testing/test/sdk_driver.go for that
l
@echoing-dinner-19531 the repo
pulumi/pulumi-dotnet
adds
pu/pu
as a git submodule and regularly bumps the version. Any reason why file
pulumi-language-dotnet/go.mod
doesn't use the submodule as a Go dependency for
pulumi/pkg/v3
and
pulumi/sdk/v3
? I expected to see lines like this:
Copy code
replace <http://github.com/pulumi/pulumi/pkg/v3|github.com/pulumi/pulumi/pkg/v3> => ../pulumi/pkg
replace <http://github.com/pulumi/pulumi/sdk/v3|github.com/pulumi/pulumi/sdk/v3> => ../pulumi/sdk
e
@ancient-policeman-24615 was trying to get rid of the submodules. yaml and hcl repos just use go dependencies, and its a little nicer. Unfortunately we still need the submodule in dotnet for the .proto files to give to the dotnet protoc, but that's all they're used for.
l
@echoing-dinner-19531 can you help me get these integrated? E.g. how to generate correct changelog, correct order of release, etc. https://github.com/pulumi/pulumi/pull/22952 https://github.com/pulumi/pulumi-dotnet/pull/1005
e
Sure I don't think you need the testdata added to the pu/pu PR. dotnet codegen doesn't run in that repo anymore Then we can merge that, pull that commit to the dotnet repo and then let everything run there.
l
@echoing-dinner-19531
pu/pu
PR adapted.
e
getting it merged
🙏 1
l
I assume you want this in a new
pu/pu
release first, before updating to that new tag in
pu/pu-dotnet
?
e
eh nah we can pull by sha in the dotnet repo
👍🏼 1
l
@echoing-dinner-19531 I bumped to the hash in my
pu/pu-dotnet
PR. Tests aren't running because I'm missing a changelog entry. EDIT: Changelog entry added.
e
Probably worth adding a changelog there, run
changie new
l
Approval needed by a maintainer to run the workflows...
1
e
I'm pretty sure this isn't 100% right but I think we'll only get it locked in correctly with a conformance test to check the runtime behaviour as well, and this isn't any worse
l
@echoing-dinner-19531 after bumping to a newer
pu/pu
, should this change be committed to my branch? https://github.com/pulumi/pulumi-dotnet/actions/runs/25676489282/job/75376853963
e
yup
can do, its just protobuf updates
l
@echoing-dinner-19531 workflows awaiting approval again...
1
e
one comment about moving Unhyphenate into csharpIdentifier
l
@echoing-dinner-19531 resolved. Can you approve the workflows again?
And side question: the code generation now un-hyphens a property to .NET casing. Now, when executing a Pulumi program using such generated code, which code path maps the .NET property correctly back to the hyphened schema property name?
e
Output annotations, but I'm not totally sure they're all correct. I'll get a conformance test written for this in the coming days though to check
l
@echoing-dinner-19531 Can you approve the workflows again?
@echoing-dinner-19531 I have a strong feeling some annotations are missing in the test example for
Bar
type with property `has-a-hyphen`:
Copy code
namespace Pulumi.Repro.Outputs
{

    [OutputType]
    public sealed class Bar
    {
        public readonly string? HasAHyphen;

        [OutputConstructor]
        private Bar(string? hasAHyphen)
        {
            HasAHyphen = hasAHyphen;
        }
    }
}
https://github.com/pulumi/pulumi-dotnet/pull/1005/changes#diff-38cc86e1d6c0095a873b3c4039024affdddb8ca573a535a5afefca03b1428857R16
e
aye, why I'm gonna add a conf test
l
@echoing-dinner-19531 you gonna merge my branch in the meantime, or continue working on top of my branch for that conf test?
e
merge in the meantime, will make some things work, and will catch the rest with a conf test
l
Then my work is ready to merge now. 🙏🏼
e
ack
🎉 1
l
@echoing-dinner-19531 you closed https://github.com/pulumi/pulumi/issues/15874. Is this covered for NodeJS too in the meantime?
e
Oh just github auto closing. I'm not sure if this works in nodejs
l
@echoing-dinner-19531 you found time to add that conf test?
e
No. Probably won't this week either, pretty busy with some new stuff but it's top of my todo list after.
l
OK. Would really like to get this "dashes" thing resolved for
dotnet
, specifically for Cert-Manager https://github.com/pulumi/crd2pulumi/issues/17
e
👍 I'll see if codex/claude are smart enough to do the grunt work on this, might be able to speed it up
Making a start at https://github.com/pulumi/pulumi/pull/23226 Flagging up a load of issues 😞
l
FYI
nodejs
is still impacted too. E.g. this CRD snippet leads to the following generated TS code:
Copy code
/**
     * SecurityLabels is the source-of-truth set of labels for this identity.
     */
    security-labels?: pulumi.Input<{[key: string]: pulumi.Input<string>} | undefined>;
e
yeh, conformance testing this flagged up its basically broken everywhere
Were still discussing what exactly we want to do here
l
Naively hinting at "capitalize properly". E.g.
security-labels
->
securityLabels
in TS. What is the dispute within the team?
e
If its right to solve this in codegen, or in crd2pulumi. What exactly we should allow for property names. If we do support things like "my-key" how do we even make that work in dynamic runtimes like nodejs and python.
l
Remember our hackathon on parameterizable providers where CRDs were the usecase? If it is still intended to phase out
crd2pulumi
by this, then I guess the right place to fix this is codegen.
e
Probably, but its not even clear if it can be fixed in codegen, so we might have to push the fix to crd2pulumi (or the new kubernetes provider with parameterisation) and it'll have to sanatize the names first
l
If you sanitize the K8s names to not contain hyphens anymore in the Pulumi schema, how do you remember to generate the correct hyphened property names for the K8s resources when using a generated SDK not containing mappings to the hyphened schema?
e
the provider would maintain the mapping as part of its parameter value
l
You're assuming parameterizable providers now, right? What if you patch it in
crd2pulumi
? You have a generated SDK and a non-parameterizable k8s provider. Where do you store these mappings in that case?
e
yeh I'm assuming paramterisation, its probably not solvable with crd2pulumi
l
😭
e
We are looking at doing the extension parameterisation, Ian and Guin have been writing up some docs and prototypes
💜 1