---
# System prepended metadata

title: GPU-enabled CI for declarative GT4Py
tags: [functional cycle 13]

---

# GPU-enabled CI for declarative GT4Py

###### tags: `functional cycle 13`

Developers: Rico, with help from Andreas F

Appetite: half a cycle

## Problem

1. declarative GT4Py has no GPU-enabled CI
2. the GPU-enabled CI for cartesian GT4Py uses the old CIGR process (not supported in the future) & could be optimized anyway
3. there is a new process in development, but in usable state

## Solution

Set up a new GPU-enabled CI for declarative GT4Py analogous to cartesian using the new process and optimize it. This might include contributing to the new process development.

## Steps

- [ ] set up new GPU-enabled CI for declarative GT4Py
    - documentation: https://gitlab.com/cscs-ci/ci-testing/containerised_ci_doc
- [ ] change it to avoid overhead installing rarely changing python dependencies every run
    - [ ] 1st stage container build contains non-python dependencies, rebuild only if dockerfile changes
    - [ ] 2nd stage container build installs python deps on top, rebuild also if dependencies specs change
    - [ ] test stage only needs to install GT4Py on top of existing python deps (faster)
- [ ] add nightly pipeline to rebuild the 2nd stage in case dependencies of dependencies change (or non-pinned dependencies update) 
    - [ ] implement nightly pipelines in the new CI process
    - [ ] add nightly pipeline to declarative CI
- [ ] document the process for when the branches are merged and cartesian should be moved to the new process

## Potential Rabbit Holes

No potential rabbit holes recognized.

## No Gos

- do not invent additional features to add to the CI process without measurable gains to GT4Py CI.