You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Users cannot currently use cmgr if they don't support building a problem from scratch and deploying it our way. This is a limitation. For example, if a user creates a windows problem and it's running on a network port, cmgr should be able to still contain the problem metadata needed for picoctf to direct a user to that challenge.
The text was updated successfully, but these errors were encountered:
If a challenge is manually deployed and managed (such as a Windows container running on some fixed host and port), then cmgr does not need to be involved in the deployment process.
Metadata-only challenges can be added directly to the picoCTF platform via the JSON file server type (in this example, the endpoint of the Windows container can be defined directly in the metadata alongside the challenge description).
As cmgr is designed to manage the lifecycle of its challenges (building images, spawning networks and containers etc.), I don't feel like it would be the right place to add this functionality. It would be strange to use the problem.md format for "metadata-only" challenges as most of its features (challenge template selection, multiple builds, {{ port/url }} templating) would not be applicable.
Users cannot currently use cmgr if they don't support building a problem from scratch and deploying it our way. This is a limitation. For example, if a user creates a windows problem and it's running on a network port, cmgr should be able to still contain the problem metadata needed for picoctf to direct a user to that challenge.
The text was updated successfully, but these errors were encountered: