[question] (pre) releases

[andreaTP]

Disclaimer: this is probably an information mostly useful for the development team and the contributors.

In #2267 we discussed about the release cycle and how this affects development. It happens that in those days I'm working hard on integration pipelines and pushing fixes upstream, I do need to have a quick feedback cycle to connect all the dots.

I found out that the create-release.yml doesn't exists anymore, so releasing from the fork becomes more tedious than only pushing a tag. I restored a version of it here to be able to self-service releases.

I imagine that this is a pain point also for the internal development team(especially for breaking changes). Keeping a version of this workflow updated should not be a lot of work and will probably benefit everyone, having to re-create it is more costly.

Thoughts?

[baywet]

Releases and pre-releases are created by the Azure DevOps pipeline. The trigger is different:

• schedule (weekly) for pre-releases
• manual tag for stable releases (gives us a bit more control)

The reason why we're on ADO for that is because this is the ONLY compliant way to do so at Microsoft. It's a real pain when for teams doing OSS as most of the compliance tasks are not available outside of Microsoft ADO orgs, which effectively means OSS contributors can't try/update our pipelines to match any major project structure changes. This is feedback we've repeatedly given to the compliance team, and movement in that area is slow, if any.

I'm not sure this answers your question though?

[andreaTP]

Thanks a lot for adding so much context @baywet !

I'm not sure this answers your question though?

This gives me context, do you think that keeping a maintained "compatible OSS alternative" of the ADO publishing CI is something the dev team has any interest in doing? I think that as soon as you start building/maintaining "integrations" for kiota such as build tool plugins etc. this will guarantee a good iteration speed.

[baywet]

We could easily update the dotnet pipeline to upload the different versions as an artifact?

[andreaTP]

The pipeline "per-se" is trivial and not an issue (it's basically a single command dotnet publish ./src/kiota/kiota.csproj -c Release -p:PublishSingleFile=true -r ${{ matrix.architecture }} -o ./${{ matrix.architecture }}), the problem here is keeping it aligned with the "official" releases with details like:

• architecture names
• zip/artifact structure
• etc.

if you and the development team will use the same mechanism for testing stuff we can share the effort(which should be minimal).

[baywet]

As far as I know, most of the development team relies on the vscode launch config when working on the generator. Relying on pipelines/actions would lead to a much longer feedback loop. I'm not sure I see the benefit here?

[andreaTP]

When working on integration tools, like Maven plugins, asdf or similar scripts being able to test the entire E2E thing is pretty useful.

[baywet]

in that context, why is it more useful than doing a local publish so you can test the integration tool quickly? (effectively what I do for the vscode extension)

[andreaTP]

in that context, why is it more useful than doing a local publish so you can test the integration tool quickly? (effectively what I do for the vscode extension)

correct I do it as well as far as it holds, but it doesn't work in CI and for remote environments.

[baywet]

aaahh I get it I think, that's because you want to be able to test the "install" part of the integration, correct? And for this, you need an actual GitHub release.

[andreaTP]

aaahh I get it I think, that's because you want to be able to test the "install" part of the integration, correct?

Yup, as well, that's the obvious initial step and I need it.

[baywet]

I think we need to separate two things here:

• testing an "install" sequence, this can rely on the GitHub releases we have on this repository as far as I can tell.
• testing generator changes, this can rely on local builds/debug profiles.

I'm not sure why would anymore need to test both at the same time?

[andreaTP]

I'm not sure why would anymore need to test both at the same time?

Because I'm connecting the dots of many moving pieces and being able to test everything together is desirable, more specifically, here I'm hacking on a full integration for Quarkus projects and being able to test changes in the integration-tests of the "installer" it's extremely convenient.

That said if you really don't see the need feel free to close this one 👍

[baywet]

To be clear, I'm not trying to push back. I'm trying to understand how many people we would be helping by doing any work in that space. Is it fair to say this is more of an end to end scenario? i.e. you've made a change in the generation logic AND you maintain an integration for which you want to showcase the latest uber-edgy changes? In which case, wouldn't it be more helpful if our weekly previews got fast-tracked to a daily release? And it'd also benefit people not building integrations.

[andreaTP]

I totally agree that this is a niche use-case, mostly for developers and integrators. E.g. you will be able to test out changes from a user's PR without having to checkout the branch/re-build etc. in addition you will be able to do it going through integration mechanisms (e.g. using tools wrapping the CLI).

In which case, wouldn't it be more helpful if our weekly previews got fast-tracked to a daily release? And it'd also benefit people not building integrations.

This is a reasonable and nice compromise to me, +1 👍

As soon as I have successfully reversed the release pipeline 🙂 : https://github.com/andreaTP/kiota-prerelease/blob/main/.github/workflows/create-release.yml

[baywet]

Thanks for clarifying this. I don't think we'll invest in pipeline changes because it's a niche ask at this point (until proven otherwise) and it's mixing two concerns.

As for accelerating the cadence from weekly to daily, I'm a bit worried we might burn people who are subscribed to releases (no way to filter between stable and pre-releases in GitHub notifications today). I'll defer to @sebastienlevert on this one.

[andreaTP]

please consider that those nightly builds can even be published to a different(e.g. non non-official) repository(even outside the Microsoft org), but it will be nice if it's somehow monitored/used by your team otherwise will go stale.

[sebastienlevert]

Do we need to release on Github every preview? Can we just ship directly to Nuget as previews and release on GitHub only the official releases?

[baywet]

Within the context of that discussion the goal is to test changes in made in the generator within the context of an integration. Most if not all integrations to date rely on github releases to "install" kiota.

[sebastienlevert]

You are right and I am terribly wrong here 😂 I'm very happy with daily releases, but I understand that this could be noisy... Do we really need to ship them within GitHub? Could we have a daily drop on a storage account somewhere that is available publicly? Do we need to have all the APIs from GitHub to ensure the integrations still work? Or we'd be OK without them? Like get the latest from this this URL (we could have it versionless and be always the latest) and store the last 30 days worth of daily builds in the same storage). I don't think this would be come a cost issue and could provide the feature we need.

[andreaTP]

Could we have a daily drop on a storage account somewhere that is available publicly?

Sounds perfect to me.

Do we need to have all the APIs from GitHub to ensure the integrations still work? Or we'd be OK without them?

Working with integrations we make it easy to change the root URL and pin specific version, I think it's fine without the GH API. 👍

[baywet]

So effectively what would be important if we deferred that to another storage account would be to follow the same URL structure as GitHub after the releases segment? How much do we want people to know about those nightly releases? Isn't moving them to a storage account going to make it hard to discover them?

[sebastienlevert]

I think it's something we can document in our Wiki for contributors as this is a fairly limited scenario. We could continue shipping weekly like we do already today (on GitHub) and ship daily (or even, really on any main merge) to the storage account. This would be a great inner loop for contributors and a great "test loop" for users.

Also, agree on the file structure on the storage account!

[baywet]

small caveat here (just want to make sure it won't matter) the vscode extension won't be able to use those drops.

[andreaTP]

the vscode extension won't be able to use those drops.

Curious about the reason, quickly looking at it and the only "caveat" would be to make this overridable by the user: https://github.com/microsoft/kiota/blob/f84da5a84fea291c503abb2df83edc46b8961670/vscode/microsoft-kiota/src/kiotaInstall.ts#L119

we usually do it with env variables: https://github.com/kiota-community/kiota-js-extra/blob/ba12b31ee4ebdd85404ea8f40620301f341ec917/kiota-gen/bin/kiota.js#L24

[sebastienlevert]

Interesting... That could mean that our VS Code extension could be decoupled from our release... Just like a setting "use previews" and it would funnel everything through the latest kiota drop.

[baywet]

Fair enough, it could read an environment variable or a vscode setting, I retract this then. I'm guessing in the case of vscode, those daily versions wouldn't go to the marketplace? only drop the vsix next to the binaries?

[baywet]

From the community call: nightly releases on github are fine, we could look into not adding the changelog for those. if we see a sharp drop of people watching the repo (from 33) it might be an indication that it's noisy and we should defer to blob storage instead.