Is the code for the wingetbot available anywhere?

[jedieaston]

I was wondering if the code for the wingetbot will ever be made available for building our own pipelines. Once self-hosted repositories are a thing, I'd like to automate the updating of line of business apps and I think it would be handy as a starting point.

Should I starting rolling my own or is this a possibility?

[denelon]

There are a few different services supporting the system today. We're planning on open sourcing, but we have some additional changes that need to be made in order to do that. One of the components is an internal tool, and we haven't seen the timeline for that becoming open source. There is also a REST API under development that should make it much easier to host your own source for packages. How would you see submissions in your scenario? Would it be centrally maintained by an IT department, or would employees be able to submit any app they like?

[jedieaston]

I would prefer that IT managed it primarily, but through a Git repo just like this. We get a new app, commit a manifest for it to a repo and then it can be consumed over the REST API. For heavily updated software like Chrome, something like the bot that could automatically open a pull request for an update would be handy for this workflow. Of course if user wanted to commit to the repo that'd be fine as well, but I think that's more of an organizational policy thing and not as much a technical problem winget needs to solve.

[denelon]

We're building a tool that will help build manifests and submit PRs. It will be open source.

[jedieaston]

Hey @msftbot, it isn't marked as requiring author feedback! Please don't close it.

[jedieaston]

Hey @msftbot, it isn't marked as requiring author feedback! Please don't close it.

[KevinLaMS]

Thanks for raising the issue. The bot will not close it.

[JanDeDobbeleer]

We're building a tool that will help build manifests and submit PRs. It will be open source.

@denelon any view on a timeline? I want to have my tool in the community repo but I refuse to manually update the manifest due to continuous delivery everywhere else.

[denelon]

@JanDeDobbeleer we're doing some internal testing with the tools now. We have a big change coming with a new manifest schema and partitioning files on GitHub to avoid display issues. The team is hard at work to validate everything and update to the new draft schema. We're hoping to get this tool out in March 2021.

[JanDeDobbeleer]

@denelon I appreciate you sharing that information SO MUCH, thank you! Looking forward to it 🙏🏻

[JanDeDobbeleer]

@denelon hope is rising as we near the end of March 😬 Any update on the timings?

[denelon]

@JanDeDobbeleer we've done some internal testing with the manifest creation tool against the 0.1 manifest syntax. That has gone fairly well, but we decided to hold off until the new v1.0 manifest schema support is in place. We're doing an internal bug bash next week. All of the work for our internal requirements to ship a product is starting to wrap up. I was targeting May 1st, but I am not super confident we'll hit that date right now. I'm hoping we aren't delayed more than a couple of weeks. I know it's not what you wanted to see, but that's where we stand. I've got the Public Service Announcement pinned as an issue in both repositories, and there are links to the new schema and the draft pull request for the specification and JSON schemas.

[denelon]

My apologies for not updating this issue sooner. It's a bit tough to cross link threads. I'm going to mention a few Issues here to help cross link things better.

#8900 - PSA: New Manifest Schema
microsoft/winget-cli#803 - PSA: New Manifest Schema
microsoft/winget-cli#157 - Create manifest wizard

[JanDeDobbeleer]

@denelon thanks. The update was exactly what I needed to know so thx. Not looking at putting more pressure on all of this, now I know what I can answer to people asking for winget support.

[denelon]

Everything takes longer than you plan even when you plan for that. The 0.1 preview of the tool has been tested, and we're very close to the release (think days, not weeks). I've even used the tool to submit a couple of manifests here.

[jedieaston]

Any updates on open-sourcing the wingetbot or the functions called in the pipelines? It would help a ton with diagnosing why an error happened so we can open an issue about it (right now the logs expose very little about what happened during the validation on the VM), and so we understand what happens during a merge (@OfficialEsco and I were talking and it's basically a bunch of guesswork as to why sometimes Moderator-Approved means an immediate merge, but sometimes it means waiting hours while nothing happens).

(Of course, some docs explaining what the wingetbot and each pipeline stage does and how it does it would also be appreciated, but maybe it's just easier to release the code? I don't know, maybe there's some secret sauce there that makes it unable to open-source).

[denelon]

@jedieaston I'm not sure about "all" of the various parts of the codebase for the bot. There are a couple of different moving parts. I'm sure you've seen some of the changes we've been making. We've heard one of the parts will be changing fairly soon to enable "code driven" bot rules. As soon as that is available, we will be checking that into the project. It will help drive clarity for several of the rules and behaviors, but not "all" of them. We have several chunks of refactoring required to be able to open source more of the validation services. Most of what holds us up is configuration and services we depend on without public interfaces. We're still discussing the best ways to share more of the code and the behaviors associated with some of the internal back end services we depend on (those are unlikely to be made open as far as I know).

[jedieaston]

That's totally fine. Anything to work off of would be great, vs "well, it failed, and nobody's going to be online from MS for two days since it's the weekend, so close and open the PR and see if it works". Especially with the lack of logs from the functions called by the pipelines (validation will sometimes run for an hour or two before it claims it failed and we don't have any idea why. It'd be nice if the validation VM could push the logs in WinGet's logs directory to Azure Pipelines or somewhere where we can read them, but that's a separate feature request).

[denelon]

The logs and clear response codes are being worked on. Where we have them, we will expose them. It's work in progress. Sadly there are many cases where the failure is just as generic internally as external. We're working with several internal teams to improve reporting/logging 😊

[denelon]

More information on the bots:

@msftbot comes from an internal project at Microsoft. It gives us flexibility to design rules (via a web UI) to respond to Issues and PRs when certain events happen (label added, comments, creation, closed, etc.). I'm not sure if / when it will be made open source. One improvement in the works is enabling a code first experience. This will allow us to commit the rules to the repository so they are visible.

One of the challenges we've had with this project has been related to busy times on GitHub. There is a retry algorithm (retry every 6 seconds for 60 seconds), but sometimes that doesn't quite work. When a webhook event is triggered, it will reset so the retry algorithm gets triggered again. This explains some of the strange behavior with PR merges. We've had extended periods of time where the "mergeability" of a PR hasn't resolved within a minute (this usually happens when several PRs are created or approved in rapid succession).

@wingetbot is used by our "custom" code to handle hooking up some of the output from our validation pipelines. It has also suffered from the same kinds of infrastructure challenges between GitHub and Azure DevOps. We have a bit more control on this one from a retry perspective. One of the other behaviors we've instrumented is a periodic scan of all open PRs. If they look to be in an inconsistent state, we automatically call "/azp run" to start the pipelines again. If that fails three times, we give up and assign the PR to an engineer.

Calling attention to moderators on this:
@OfficialEsco, @ItzLevvie, @jedieaston

[jedieaston]

When a webhook event is triggered, it will reset so the retry algorithm gets triggered again.

Ah! That's why when a PR gets stuck and someone just clicks "approve" (even if they aren't a mod) msftbot gets its act together and merges. It must be listening for pull_request_review.

Would it be possible to give @wingetbot the power to merge into master and have it periodically scan for open PRs with Moderator-Approved and merge them itself via the Merge a Pull Request endpoint, bypassing @msftbot entirely? Then you would have the power to scale it up as needed.

[denelon]

We've been discussing the implications of having two different places to manage merge behavior. We would prefer to have code in one place, but your suggestion might make sense. We could consider adding that to the PR scanner code, but we don't know what would happen in the event of a race condition between two bots attempting to do the same thing.

[jedieaston]

Any updates on logging? Or documenting everything that validation does (to the extent that it can be public)? Or open sourcing some of it?

please?

it’s what the people want

(I just noticed this hadn’t been touched in two months, so just wanted to check in).

[jedieaston]

Related: #30513.

[vedantmgoyal9]

@denelon Any updates on this one? I (and @jedieaston) am/have been waiting for so long for @wingetbot's code to be open-sourced.

[denelon]

The code for @wingetbot is deeply integrated into some of our "closed source" validation logic. I've been talking with the team about some refactoring to be able to expose it. We've been doing some "branch by abstraction" work to be able to expose it, but we've prioritized getting other features/bugs fixed. The team is actively working on it to improve validation, so some of the work to make more of it open source has necessarily taken a back seat.

We haven't been getting many asks for duplicating what we're doing via GitHub as opposed to just making a simpler private source implementation along with the tooling to import/export from other sources.