rseng-ci-cdlisted

# Continuous integration and delivery for research software Use this skill when a project needs to automate its build, test and release path, or when someone is deciding how to run CI for research software. It covers CI/CD concepts, GitHub Actions, GitLab CI/CD, and hybrid setups where a GitHub project runs on an organization's GitLab runners. Prefer concrete, minimal pipelines first, then grow them; do not scaffold monitoring, mirroring or multi-runner infrastructure a small project will not use. ## Core concepts Distinguish the three practices before recommending tooling: - Continuous Integration (CI): integrate code changes into a shared repository frequently, and verify every change with an automated build that compiles and runs tests. Catches integration errors early. - Continuous Delivery (CD): keep software always in a deployable state; the release to production stays a manual decision. Value: fast, safe rollbacks and few manual release steps. - Continuous Deployment (CD): go further and deploy every passing change to production automatically, with no manual gate. When advising, name which of the three the user actually wants. Most research projects need solid CI plus Continuous Delivery, not fully automated Continuous Deployment. ## What a pipeline should cover Map the project's needs onto these stages before writing YAML: - Automated builds triggered on every change (compile plus tests). - Version-control integration so commits and pull requests tri