Move the categories to the nuspec & Add wiki page with tools by categories

[Ana06]

Details

Use GH actions to have two Wiki page that documents the tools and categories:

• One page should be for users with a header and a table with package name, tool name and tools description per category. This should make it easier to find the tools that we have available.
• The second page should be for script usage to use it in FLARE-VM/Commando-VM to sort the packages by category in the installer.

[Ana06]

I have discussed with @sara-rn the following implementation proposal, which is more robust than the original proposal:

• Add a single Packages Wiki page with a table with package name, tool name and tools description per category. This should make it easier to find the tools that we have available. This is addressed in Add GitHub Action to Create Package Wiki #1197.
• Move the categories to the nuspec. This way we can use the XML https://www.myget.org/F/vm-packages/Packages directly in the FLARE-VM/Commando-VM installers to sort the packages by category (tracked in FLARE-VM in Display packages by category in installer flare-vm#578) and we do NOT need and extra wiki page generated by GH actions. @sara-rn is working on this part. The move of the categories to the nuspec involves:
  • Add the category to the nuspec of all packages (for example in the tags field).
  • Adapt installers and linter. In the packages that use the category to install a shortcut in the Tools directory, take it from the nuspec instead of hard-coding it. I think this should be easy to do, but in case this is not possible, we should add a linter to ensure they are on-sync. In any case, we should adapt the category linter to ensure the nuspec uses a valid category and that the category is accessed in the correct way. We may want to split this into two linters. The changes described in this bullet point need to be in the same PR.
  • Adapt the Packages wiki page introduced in Add GitHub Action to Create Package Wiki #1197 to use the category from the nuspec. I think this is a nice improvement, as it removes the Not Categorized section making this page more useful.

As moving the categories to the nuspec and changing how they are accesses in the install scripts touches all packages. So I recommend we try to merge all PRs that would cause conflicts before sending this change and try to send small atomic PR if possible. For example, adding the categories to the nuspec could be an independent PR.

[Ana06]

Part of this issue (moving the categories to the nuspec) is still not addressed.

[Ana06]

More detailed proposal to move categories to the nuspec

1. Add the category to the nuspec of ALL packages in the tags field. Note you may need to introduce new categories for some packages that don't have a category ATM like IDA plugins, as we plan to display this category to the user in the installer. We should try to keep the number of categories small and use existent categories if possible. For example libraries.python3.vm can have the existent Python category.
2. Add a new linter to lint.py, which ensures the category in the nuspec is a valid one. This linter implementation should be similar to the current UsesInvalidCategory, but the exceptions should be only the packages that we do not plan to display to the user: installer.vm and debloat.vm.
3. Implement a VM-Get-Category function in common. To implement this function you first need to look for the nuspec file using $MyInvocation.MyCommand.Definition and them get the tags field from it. $MyInvocation.MyCommand.Definition gives you the path of the current chocolateyinstall.ps1 file, for example C:\ProgramData\chocolatey\lib\capa.vm\tools\chocolateyinstall.ps1. So you can easily get the package folder (that contains the nuspec) with something like Split-Path -parent (Split-Path -parent $MyInvocation.MyCommand.Definition). Note we use already $MyInvocation.MyCommand.Definition in many packages, such as libraries.python3.vm
4. Replace the $category = '{category}' line in the chocolateyinstall.ps1 and chocolateyuninstall.ps1 by $category = VM-Get-Category and adapt the linter UsesInvalidCategory to look for the line $category = VM-Get-Category for all not excluded packages.
5. Update create_package_template.py to add the category in the nuspec and use $category = VM-Get-Category in chocolateyinstall.ps1 and chocolateyuninstall.ps1
6. Adapt the Packages wiki page introduced in Add GitHub Action to Create Package Wiki #1197 to use the category from the nuspec. Only include packages with a category in the nuspec (ALL with the exception of installer.vm and debloat.vm).
   @sara-rn please follow this implementation in order and send a separate PR for every of the number items.

[sara-rn]

Thanks @Ana06 for the suggestions, this makes it easier to implement as there were different ways to implement it and also it would imply changing many files, therefore this order of implementation with separate PRs help.
I just miss another step, the last one, which would be 6. Change the ISSUE templates and the create package script to include this implementation. Let me know if this should be implemented as the last PR

[Ana06]

@sara-rn you only need to update the categories in the ISSUE TEMPLATES. This should be done together with the categories linter as they are supposed to be on sync. See #298.

[Ana06]

@sara-rn you are right that the script to create packages also needs to be updated. I have update the list above to explicitly include it.

[Ana06]

This PR was closed automatically by #1272 as @sara had added Closes #1107 to the description. But that PR does not close this issue, as it is just one step, all the items above need to be addressed. Until we have enabled back the linter (WIP in #1287) we can't consider this done. In addition, we still need to update the action for the wiki page.

[Ana06]

This issue has been closed again! 😠 @sara-rn all the following keywords close automatically the referenced issue:

close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved

You can use <KEYWORD> (partially) #issue to reference the issue without closing it, but if you use <KEYWORD> #issue it is closed automatically:

Check GitHub documentation about Linking a pull request to an issue using a keyword for more details.

[Ana06]

Only adapting the GH workflow that generates the Wiki page missing here.