GitHub Interoperability - by Project

GitHub Interoperability

Why

Today, we find are manually copy+paste source code from QC to GitHub and back. Trying to maintain versions of QC code by live deployment and backtests which meet our criteria. The manual process is slow, error prone and unnecessary.

Scenarios / Use Cases

1. Create a QuantConnect project from a branch in GitHub (the branch would need some required files for setup possibly)
2. On each backtest, since the code from the main QC Project is already 'snapshot' to run the backtest; create a GitHub branch in said repository to match the backtest codebase
3. On Live Deploy - create branch in said repository
4. Create a functionality in which the post-backtest outputs (metrics, trades, orders, other) are commit, push to the Branch associated with the backtest branch previously created

Misc

• Other functions such as creating issues or other GitHub specific detail can all be managed on the GitHub side.
• Such as a GitHub Action "ON" event, parsing for a naming convention.
• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#on
• Name convention possibility for each branch name creation

snapshot/<project-name>.<unique id>.<datetime stamp>
backtest/<project-name>.<unique id>.<datetime stamp>
live-deploy/<project-name>.<unique id>.<datetime stamp>

No files, tests, or entry points are named. Start by breaking the four scenarios into separate requirements and identifying how lean-cli currently represents projects, backtests, and live deployments. Done should include an agreed GitHub branch convention, project synchronization behavior, and post-backtest output handling.