Create a GitHub action which regularly executes GLVD2. It should also cache its repo and submodules to avoid unnecessary refetches all the time.
When this issue is implemented also decide, which parts of GLVD2 have to run regularly. We could split the application into an ingestion action (for external sources), an internal processing one, and one to generate the static outputs. If this is the best split and how it should be executed is best to be decided then. Also depends on how the actual interaction with the GitHub bot will be done. So, the bot could require regular reruns, which we maybe do not want to link to fetch external submodules like cvelistV5.
We could create separate binaries or just use different commands inside our one binary.
Create a GitHub action which regularly executes GLVD2. It should also cache its repo and submodules to avoid unnecessary refetches all the time.
When this issue is implemented also decide, which parts of GLVD2 have to run regularly. We could split the application into an ingestion action (for external sources), an internal processing one, and one to generate the static outputs. If this is the best split and how it should be executed is best to be decided then. Also depends on how the actual interaction with the GitHub bot will be done. So, the bot could require regular reruns, which we maybe do not want to link to fetch external submodules like cvelistV5.
We could create separate binaries or just use different commands inside our one binary.