Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New Feature]: Allow multiple manifest deletions in single PR #83295

Open
Alphrag opened this issue Oct 12, 2022 · 2 comments
Open

[New Feature]: Allow multiple manifest deletions in single PR #83295

Alphrag opened this issue Oct 12, 2022 · 2 comments
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.

Comments

@Alphrag
Copy link
Contributor

Alphrag commented Oct 12, 2022

Description of the new feature/enhancement

In the current situation, in order to delete the manifest of a version of a package, a PR needs to be created with the deletion of the appropriate files for that version and if multiple versions should be deleted, a PR has to be raised for each of them separately, since the bot pipeline requires that only one package is modified.

I think that it should be possible to delete multiple versions in one go (e.g. #83292) instead of having to create a separate PR for each version, as this takes more time for everyone involved.

I know that some people would argue that manifests should not be deleted if the source could still be accessed, but I can see different places where this would come handy or necessary. For example, old testing versions that are missing security features, or breaking changes of a backend which are not backward compatible with versions too far behind.

Proposed technical implementation details (optional)

I see two possibilities to deal with that:

  1. Create a type of PR aimed only at version deletions: this would be done by requiring an appropriate string at the end of the PR name to be added (something like [version deletion]), which would trigger the different testing pipeline than the usual to only verify that the whole folder is appropriately deleted (not leaving a partial manifest behind).
  2. Modify the testing pipelines, so that deletions are counted separately from manifest creation/modification: this would mean that the pipeline would first verify that all deletions correspond to full versions, and if this pass accordingly, it would only look at the remaining created/modified files and run in the usual way.

I am aware that each of these might involve quite some work in one way or another, and have both their pros and cons. The main advantage of 1. that I see is that it will save resources by not running the full testing pipeline, but a much simplified version, while option 2. has the advantage of not changing the current workflow of the PRs through the wingetbot and involve "only" a change on the testing pipeline flow.

There are probably other (possibly better) ways to implement that, but I would be happy to see this coming forward, which would allow to unclutter a bit the manifest folder.
Thanks.

@Alphrag Alphrag added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Oct 12, 2022
@ghost ghost added the Needs-Triage This work item needs to be triaged by a member of the core team. label Oct 12, 2022
@Trenly
Copy link
Contributor

Trenly commented Oct 12, 2022

Seems like this is similar to #125 but focused solely on deletions

@Alphrag
Copy link
Contributor Author

Alphrag commented Oct 12, 2022

Seems like this is similar to #125 but focused solely on deletions

Yes, you are right. Sorry I didn't see that issue when I searched through the opened ones. Feel free to close this one if you think this should be considered as duplicate, or to keep it open if the suggestion of separation between deletion and creation of manifests on the testing pipeling could be an idea worth of staying separate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Projects
None yet
Development

No branches or pull requests

3 participants