Answers: <p>I would suggest to use the <a href="https://docs.gitlab.com/ee/ci/jobs/job_control.html#fetch-artifacts-from-a-parallelmatrix-job" rel="nofollow noreferrer">parallel matrix feature</a> of GitLab CI (see also <a href="https://docs.gitlab.com/ee/ci/yaml/index.html#parallelmatrix" rel="nofollow noreferrer">here</a>). As Bruce Becker suggested utilizing <code>tox</code> is also a valid option and exactly designed for your use case.</p>
  <pre><code>build:
    image: python:${PY_VERSION}
    parallel:
      matrix:
        - PY_VERSION: [&quot;3.7&quot;, &quot;3.8&quot;, &quot;3.9&quot;]
    script: poetry build
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2022-06-27T07:02:42.190Z
Answers: 2022-06-27T07:07:49.950Z
Answers: 2022-06-27T07:07:49.950Z
Answers: YoshiMbele
Answers: <p>One could use Gitlab templates in conjunction with an environment variable that sets the python version.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-09-26T18:37:12.237Z
Answers: 2021-09-26T18:37:12.237Z
Answers: 030
Answers: <p>You can parametrize GitLab pipeline using <code>variables</code> keyword in <code>gitlab-ci.yaml</code>:</p>
  <pre><code>variables:
    PYTHON_VERSION:
      value: &quot;3.7&quot;
      options:
        - &quot;3.7&quot;
        - &quot;3.8&quot;
        - &quot;3.9&quot;
      description: &quot;Python version&quot;
  </code></pre>
  <p>You can see a sample GitLab <code>gitlab-ci.yaml</code> using <code>variables</code> keyword at <a href="https://gitlab.com/warrior7089/gitlab-parameterized-pipelines-demo/-/blame/main/.gitlab-ci.yml#L10" rel="nofollow noreferrer">my GitLab</a> or read an article about <a href="https://rokpoto.com/gitlab-parameterized-pipelines/" rel="nofollow noreferrer">GitLab Parameterized Pipelines</a>.</p>
  <p>Disclaimer: I wrote the above article.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-09-24T18:33:53.687Z
Answers: 2023-09-24T18:33:53.687Z
Answers: rokpoto.com
Body: <p>There is the following simple pipeline:<br />
  <code>build</code> → <code>test</code> → <code>deploy</code><br />
  that uses specified <code>python</code> version for all stages, for example <code>3.8</code>.</p>
  <p>How can I scale (parametrize) it for <code>python</code> with versions: <code>3.7</code>, <code>3.8</code> and <code>3.9</code>?<br />
  Simplest solution that comes to mind is to create 3 different pipelines with hardcoded <code>python</code> versions:<br />
  <code>build_37</code> → <code>test_37</code> → <code>deploy_37</code><br />
  <code>build_38</code> → <code>test_38</code> → <code>deploy_38</code><br />
  <code>build_39</code> → <code>test_39</code> → <code>deploy_39</code>.</p>
  <p>I know this is a very bad solution.<br />
  What is the right way?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-09-21T13:51:34.327Z
Comments: this sounds like a pretty cut-and-dry use case for [Tox](https://pypi.org/project/tox/) - have you tried that?
Comments: Bruce Becker
Tags: <continuous-integration><gitlab><python>
Title: Parametrize gitlab ci pipeline
UserDisplayName: Arseny
ThreadText: # Parametrize gitlab ci pipeline
  
  (Asked by: username_0 on 2021-09-21)
  
  There is the following simple pipeline:  
  `build` → `test` → `deploy`  
  that uses specified `python` version for all stages, for example `3.8`.
  
  How can I scale (parametrize) it for `python` with versions: `3.7`, `3.8` and `3.9`?  
  Simplest solution that comes to mind is to create 3 different pipelines with hardcoded `python` versions:  
  `build_37` → `test_37` → `deploy_37`  
  `build_38` → `test_38` → `deploy_38`  
  `build_39` → `test_39` → `deploy_39`.
  
  I know this is a very bad solution.  
  What is the right way?
  
  **Tags:** continuous-integration, gitlab, python
  
  > **Comments:**
  > **username_1**: this sounds like a pretty cut-and-dry use case for [Tox](https://pypi.org/project/tox/) - have you tried that?  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_2 on 2022-06-27. Score: 3
  
  I would suggest to use the [parallel matrix feature](https://docs.gitlab.com/ee/ci/jobs/job_control.html#fetch-artifacts-from-a-parallelmatrix-job) of GitLab CI (see also [here](https://docs.gitlab.com/ee/ci/yaml/index.html#parallelmatrix)). As username_1 suggested utilizing `tox` is also a valid option and exactly designed for your use case.
  
  ```
  build:
    image: python:${PY_VERSION}
    parallel:
      matrix:
        - PY_VERSION: ["3.7", "3.8", "3.9"]
    script: poetry build
  
  ```
  
  
  ---
  
  ### Answer by username_3 on 2021-09-26. Score: 1
  
  One could use Gitlab templates in conjunction with an environment variable that sets the python version.
  
  
  ---
  
  ### Answer by username_4 on 2023-09-24. Score: 0
  
  You can parametrize GitLab pipeline using `variables` keyword in `gitlab-ci.yaml`:
  
  ```
  variables:
    PYTHON_VERSION:
      value: "3.7"
      options:
        - "3.7"
        - "3.8"
        - "3.9"
      description: "Python version"
  
  ```
  
  You can see a sample GitLab `gitlab-ci.yaml` using `variables` keyword at [my GitLab](https://gitlab.com/warrior7089/gitlab-parameterized-pipelines-demo/-/blame/main/.gitlab-ci.yml#L10) or read an article about [GitLab Parameterized Pipelines](https://username_4/gitlab-parameterized-pipelines/).
  
  Disclaimer: I wrote the above article.
  
  
  ---
  
  