CI

To make CI similar to that in python cookicutter, I think we can incorporate the below.

Description

Create an Action to Setup Funnel:
- Create a directory .github/actions/setup/funnel.
- Define the Funnel setup in action.yaml.
Testing:
- Separate unit and integration tests in CI:
  - Unit tests: cargo test --verbose.
  - Integration tests: cargo test --test integration_test --verbose.
- Generate and upload coverage to Codecov for both unit and integration tests:
  - Use cargo-tarpaulin to generate coverage reports.
  - Upload coverage reports to Codecov.
  - Add Codecov badge to README.md.
Pre-commit Checks:
- Add checks for formatting, large files, and EOF format to pre-commit.yaml.
- Ensure checks are included in CI.
PR Evaluation:
- Copy PR evaluation workflow from the cookiecutter dev branch.
- Add local and build jobs to the PR evaluation workflow.
Docs:
- Configure clippy to enforce documentation.
- Decide between publishing docs to gh-pages or crates.io.
Publish:
- Add a publish CI workflow for crate releases and documentation.
Issue and PR Templates:
- Copy PULL_REQUEST_TEMPLATE.md and general-purpose.md from cookiecutter with minimal language-specific changes.
Makefile:
- Add development commands to Makefile for ease of use, based on cookiecutter's Makefile.
Directory Structure Update:
- Ensure .github directory contains:
  - actions/setup/funnel/action.yaml for Funnel setup.
  - workflows with YAML files for:
  - code_quality.yaml (format, lint, spell check).
  - code_test.yaml (unit and integration tests).
  - docs.yaml (publishing documentation).
  - pr_validation.yaml (PR evaluation and build).
  - release.yaml (crate release).
  - Add .pre-commit-config.yaml for pre-commit hooks.
  - Update .yamllint.yaml for YAML linting.

Summary

[ ] Setup Funnel Action
[ ] Testing
[ ] Pre-commit Checks
[ ] PR Evaluation
[ ] Docs
[ ] Publish Workflow
[ ] Issue and PR Templates
[ ] Makefile

PS: @uniqueg @pavelnikonorov @aaravm please change/edit this issue as you need, I just wrote what a list of CI that I think might/would be needed :).

@aaravm and I had a chat regarding CI, so here is some of my points on it.

This is in respect to dev branch.

Below is the structure for CI used in python proj using cookicutter.

.
├── actions
│   └── setup
│       └── poetry
│           └── action.yaml
├── ISSUE_TEMPLATE
│   └── general-purpose.md
└── workflows
    ├── code_quality.yaml
    ├── code_test.yaml
    ├── docs.yaml
    ├── pr_validation.yaml
    ├── release.yaml
    ├── update.yaml
    └── vulnerability.yaml

Create an action to setup up funnel: Since funnel is needed for testing, its implementation should be abstracted from the CI and then used in the supposed code_test.yaml.
Testing:
- Separation of tests: unit test will be in the same file but integration will be in tests/ dir. This gives separation for CI so we can see which failed.
```
# In unit test job
- name: Run unit tests
run: cargo test --verbose
# In integration test job
- name: Run integration tests
run: cargo test --test integration_test --verbose
```
- Codcov: You can use tarpaulin or any of the coverage tool listed at codecov to generate and upload the tests to codecov. You would need to do that for both unit and integration test (add the badge of codecov in README.md).
```
# in integration test job
```
- name: Generate integration test coverage run: | cargo tarpaulin --tests --out Xml --output-dir ./coverage/integration continue-on-error: true
- name: Upload coverage to Codecov uses: codecov/codecov-action@v3 with: files: ./coverage/integration.xml flags: unittests integration name: codecov-umbrella fail_ci_if_error: true
Pre-commit: There are certain checks which are not dependent on runtime or non code test, I prefered to add those to pre-commit.yaml, and add a check in CI, this way dev is not obligated to pass the pre-commits to push but it give a good overview in the CI if there were any violations of checks like, wrongly formatted md file, or a extremely large file was pushed by mistake or if the files have correct EOF format.
PR evaluation: You can copy this from this exactly from cookiecutter dev branch.
- Build: Put you local.yaml and build.yaml here itself as job.
Docs: clippy would enforce writing docs for the code being published with that we could just publish that on gh-pages but maybe better would be to publish this on crates.io and not worry about docs, because then the documentation is automatically generated and hosted on docs.rs. This
```
    # clippy.toml
    warn(missing_docs)
```
Publish: Add a publish CI this will help release the crate and also give us docs.
PULL_REQUEST_TEMPLATE.md And general-purpose.md issue template: Copy it from cookicutter, with minimal language specific changes.
Makefile: Add commands for ease of dev.

So it would look something like

.
├── .github
│   ├── actions
│   │   └── setup
│   │       └── funnel
│   │           └── action.yaml  // Setup funnel
│   ├── ISSUE_TEMPLATE
│   │   └── general-purpose.md  // Copy from cookicutter.
│   └── workflows
│       ├── code_quality.yaml  // Format (fmt), and lint (clippy), and spell check (https://crates.io/crates/cargo-spellcheck)
│       ├── code_test.yaml  // 2 jobs integration and unit tests.
│       ├── docs.yaml  // dependends on if you choose to publish.
│       ├── pr_validation.yaml // Copy from cookicutter and then add build step here as well.
│       ├── release.yaml  // Crate release CI
├── .gitignore
├── images
│   ├── logo-elixir-cloud-aai.svg
│   └── logo-elixir.svg
├── LICENSE
├── Makefile  // To make dev easy, add dev commands here, look into cookicutter's makefile.
├── .pre-commit-config.yaml
├── PULL_REQUEST_TEMPLATE.md
├── Cargo.toml
├── lib
├── README.md
├── tests
└── .yamllint.yaml  // Use this to enforce yaml linting in pre-commit in CI.

PS: @uniqueg @pavelnikonorov thoughts?

elixir-cloud-aai / ga4gh-sdk

ci: setup CI #32

CI

Description

Summary

Makefile: Add commands for ease of dev.