docs: combine trivy.dev into trivy docs

[itaysk]

Description

Today we have https://trivy.dev as the homepage for Trivy, and https://aquasecurity.github.io/trivy as the documentation site. This is suboptimal because:

1. the docs contains the most interesting and relevant content
2. it's not easy to update trivy.dev, this cause us to put "website content" in the docs
3. huge gap in look and feel
4. confusing to users - where shold be the go-to place for info on trivy
5. there's duplicate content between the marketing/informational site and docs

This PR takes the theme and some elements from trivy.dev and adds a new homepage to the current docs site, so that the current docs site can become the one place with all of Trivy's content.
Additionally, there are some content changes (especially in getting started) in the docs to make it more suitable for the new structure.

This is to kick-off the new website motion, in the future I suspect we will do some more revisions on the docs sections, and also add more content to the homepage which currently is minimal.

since this is a large PR, best to process it by commits.

[itaysk]

I think this is ready for review now. I might change the quotes abit, and possibly copy the users avatars to serve locally, but otherwise it's ready

(of course, we will iterate on the content over time)

[knqyf263]

Failing
https://github.com/aquasecurity/trivy/actions/runs/11723992098/job/32656873639?pr=7884

[itaysk]

Failing

I missed updating this workflow since it's name didn't follow the other docs workflow names. besides fixing the build. should I rename this from test-docs to mkdocs-test so that it appears together with other related workflows?

[itaysk]

the job succeeds now. just so confirm - since it's missing the --push flag, it will not push the docs to gh pages, so it probably meant checks that the site generates without errors and CAN be deployed. the reason I'm mentoining this is that I do see we have a test label in the version picker on the read docs site, but the last push there was a year ago.

[knqyf263]

should I rename this from test-docs to mkdocs-test so that it appears together with other related workflows?

It depends on how we categorize this workflow. test-docs.yaml and mkdocs-latest.yaml have different roles, testing or deploying. It was initially defined in test.yaml because the doc test should be triggered on every PR. It was then separated into test-doc.yaml because it was waste of time to run a test of the documentation every time the documentation was not changed. So, it is like a part of tests. From this perspective, the file name follows the convention.

If you consider this workflow is more like mkdocs things rather than testing, I'm totally fine with the change. I just explained the reason behind that.

[knqyf263]

the job succeeds now. just so confirm - since it's missing the --push flag, it will not push the docs to gh pages, so it probably meant checks that the site generates without errors and CAN be deployed.

Yes, that is the intention. I don't remember, but we probably used test for manual testing because the production and the local environments are slightly different due to mkdocs-material-insiders. Since we developers don't have access to mkdocs-material-insiders, we needed to push the changes to GitHub Pages if we really wanted to see the final document.

trivy/.github/workflows/mkdocs-latest.yaml

Line 27 in 99b2db3

pip install git+https://${GH_TOKEN}@github.com/squidfunk/mkdocs-material-insiders.git

We can remove test if it's confusing.

[simar7]

I think we need to fix the search box on the landing page as it seems to be constrained

[itaysk]

search box on the landing page as it seems to be constrained

Thanks, I've identified a work around but looking for a more elegant fix