Update chip support pages

[f-hollow]

Description

The following updates are planned:

• The dynamically fetched file .md is turned into .json with a number of key-value pairs.
  • Features in markdown
  • Other projects in markdown
  • Timestamp when info was generated
• These fields will be populated in different places of chip support pages.

Related

• Create page for chip support status #377

Testing

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[horw]

Hi!

I think it’s an interesting topic to discuss where you load your JSON files from.
There are a few options:

• Load them under your domain.
• Load them under another trusted domain.
• Load them from any domain.

Another question is how you control your JSON versions. Do you want to manage their changes, or not at all?

If we don’t rely on third-party APIs and our JSON files are just semi-static metadata, it’s a good idea to minimize the number of sources. For example, storing them on the same domain can simplify things. This eliminates the need to deal with CORS issues. However, in this case, we must carefully review what we upload to our server and ensure that the files are not accidentally removed, on the other hand, we also need to consider the limitations on who can upload these files.

Regarding the limitations mentioned above, a dedicated repository can help us solve these issues. We can create a repository, such as a specification files(just example) repository, to hold the files. After a review, updates could be pushed to the server via a workflow pipeline. This approach ensures that the files are reviewed, maintains a centralized location for restoration, streamlines the update process, and ensures that only the pipeline has access to push files.

[f-hollow]

Hi!

I think it’s an interesting topic to discuss where you load your JSON files from. There are a few options:

* Load them under your domain.

* Load them under another trusted domain.

* Load them from any domain.

Another question is how you control your JSON versions. Do you want to manage their changes, or not at all?

If we don’t rely on third-party APIs and our JSON files are just semi-static metadata, it’s a good idea to minimize the number of sources. For example, storing them on the same domain can simplify things. This eliminates the need to deal with CORS issues. However, in this case, we must carefully review what we upload to our server and ensure that the files are not accidentally removed, on the other hand, we also need to consider the limitations on who can upload these files.

Regarding the limitations mentioned above, a dedicated repository can help us solve these issues. We can create a repository, such as a specification files(just example) repository, to hold the files. After a review, updates could be pushed to the server via a workflow pipeline. This approach ensures that the files are reviewed, maintains a centralized location for restoration, streamlines the update process, and ensures that only the pipeline has access to push files.

@ginkgm

[f-hollow]

@ginkgm Direct link to the ESP32-C61 chip support page:

https://preview-developer.espressif.com/pr376/pages/chip-support-status/esp32c61/

[github-actions]

🎉 A preview for this PR is available at: https://preview-developer.espressif.com/pr376/