search

renovatebot / renovate

Home of the Renovate CLI: Cross-platform Dependency Automation by Mend.io
https://mend.io/renovate
GNU Affero General Public License v3.0
17.56k stars 2.3k forks source link

Replace programming language with categories #13953

Closed secustor closed 1 year ago

secustor commented 2 years ago

Describe the proposed change(s).

The other category of the manager docs has become quite big.

I propose following refactor to improve visibility for new users:

manager old category new category
ansible docker ansible
ansible-galaxy ansible
argocd kubernetes (cd?)
azure-pipelines ci
batect batect
batect-wrapper batect
bazel
bitbucket-pipelines ci
buildkite ci
bundler ruby ruby
cake dotnet dotnet
cargo rust rust
cdnurl cd?
circleci ci
cocoapods swift
composer php php
deps-edn jvm
docker-compose docker docker
dockerfile docker docker
droneci docker ci
flux kubernetes (cd?)
git-submodules
github-actions ci
gitlabci docker ci
gitlabci-include ci
gomod golang golang
gradle java jvm
gradle-wrapper jvm
helm-requirements helm
helm-values helm
helmfile cd?
helmsman cd?
helmv3 helm
homebrew
html cd?
jenkins ci
jsonnet-bundler kubernetes
kubernetes docker kubernetes
kustomize kubernetes
maven java jvm
meteor js js
mix elixir elixir
nodenv node node
npm js js
nuget dotnet dotnet
nvm node node
pip-compile python python
pip_requirements python python
pip_setup python python
pipenv python python
poetry python python
pre-commit
pub dart
pyenv python python
poetry python python
regex
ruby-version ruby ruby
sbt jvm
setup-cfg python python
swift swift
terraform terraform
terraform-version terraform
terragrunt terraform
terragrunt-version terraform
travis ci
viceice commented 2 years ago

I think we should fully remove the languages and add a new tags option which can have multiple values.

This should also be matchable via package rules.

rarkins commented 2 years ago

Maybe the term "category". I would like to remove language as a semantic concept including from package rules

rarkins commented 2 years ago

In most cases it would be better replaced by datasource matching in package rules

HonkingGoose commented 2 years ago

Use list styling for long lists

We have too many managers under the other category, and it's hard to read because its not styled like a list.

Until we rewrite the code to the new structure, could we at least make long items like this go in a list? Like this:

Supported Managers

...snip...

Other:

  • ansible-galaxy
  • argocd
  • azure-pipelines
  • And so on

I'd want us to change the supported datasources section as well, so it looks like this:

Supported Datasources

Supported values for datasource are:

  • adoptium-java
  • artifactory
  • aws-machine-image
  • And so on

Use tags feature in Material for MkDocs???

This might be relevant/helpful. If you sponsor Material for MkDocs, you get access to the tags feature. Quote from feature page:

Material for MkDocs adds first-class support for categorizing pages with tags, which adds the possibility to group related pages and make them discoverable via search and a dedicated tags index. If your documentation is large, tags can help to discover relevant information faster.

I have not tried this feature, so I don't know if it would make things better for us. The Material for MkDocs, setting up tags documentation has some screenshots that you can look at.

secustor commented 2 years ago

I think to have option to give managers multiple categories is definitely useful. e.g. helmsman and helmsfile could have helm as well as cd .

In most cases it would be better replaced by datasource matching in package rules

I think there are enough use cases like ansible and ansible-galaxy where it not visible to the users which data sources they can expect.

rarkins commented 2 years ago

I have an issue open to discuss making managers declare their supported datasources so that we can convert that to docs

HonkingGoose commented 2 years ago

I have an issue open to discuss making managers declare their supported datasources so that we can convert that to docs

@rarkins It sounds like you're thinking of this issue?

secustor commented 2 years ago

To summarize, the requirements are so far:

The topic of long lists and MkDocs tags earns an own issue IMO.

HonkingGoose commented 2 years ago

@rarkins what's the best order to tackle these items?

rarkins commented 2 years ago

I think more generally:

  1. We need config warnings to be more visible

Dashboard is mostly sufficient, but I think sometimes content is "lost". For config warnings, we should make sure the message is sufficient.

I think we could also add a message to each PR which says something like ":warning: this repository has warnings. Please check the logs of Dependency Dashboard for details". This should draw more attention.

  1. We should deprecate languages

This should last for enough time so that people have the chance to see the warnings and change their config. We may want to give a guide to migrating from them in the docs.

  1. We remove languages support in a major release

Major bumps don't help repo users - only admins - so that's why we need (2) above to try to alert people first.

Back to the original point, our language-based grouping of managers in docs is not great. I think we could change the docs grouping - whether manually or automatically using categories - independently of the above languages deprecation.

secustor commented 2 years ago
  1. We need config warnings to be more visible
  2. We should deprecate languages
  3. We remove languages support in a major release
  1. Already implemented: https://github.com/renovatebot/renovate/pull/9349
  2. TODO
  3. TODO

Implementation of categories:

renovate-release commented 1 year ago

:tada: This issue has been resolved in version 36.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: