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

[itaysk]

as part of this change, we will also need to redirect trivy.dev to this gh pages site.

From: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site

Under "Custom domain", type your custom domain, then click Save. If you are publishing your site from a branch, this will create a commit that adds a CNAME file directly to the root of your source branch. If you are publishing your site with a custom GitHub Actions workflow, no CNAME file is created, so you need to create one manually (containing only a line of text with your custom domain).

I thought that we fall into the GH Actions category but it appears we aren't.
I learned that GH now allows us to choose a "publishing source" that configures GH Pages to use the automatic build with Jekyll OR to defer to a GH Action to build and push the site. As far as I understand for our scenario we should be using "GitHub Actions source", but are currently set to "Deploy froma branch source". We can also observe the pages build and deployment that confirms this.
I didn't change our source to GH Actions because it seems that it requires changes to the publishing workflow. If I understand it correctly (honestly not sure) we would need to add another step after pushing the html to the branch, publishes the new version to GH pages. For reference, this is the WF that GH suggests when choosing the GH Actios source: https://github.com/aquasecurity/trivy/new/main?filename=.github%2Fworkflows%2Fstatic.yml&pages_workflow_template=pages%2Fstatic
IMO I prefer to minimize risk now and keep using branch source, but mentioning here for the record.

In this case, I will add the trivy.dev as custom domain in the UI, which will create the CNAME file in the docs branch, and mike should not have an issue with this, as mentioned here: https://github.com/jimporter/mike#cname-and-other-special-files.

[itaysk]

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

fixed