Answers: <p>You can use <code>rules</code> in gitlab ci to control when you want to stage to be executed: <a href="https://docs.gitlab.com/ee/ci/yaml/index.html#rules" rel="nofollow noreferrer">https://docs.gitlab.com/ee/ci/yaml/index.html#rules</a></p>
  <p>e.g. set rules to only publish package when branch name is <code>master</code>.</p>
  <p>You can even use regex for filtering branch name.</p>
  <p>Hope it helps.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-02-04T09:21:28.237Z
Answers: This would break my workflow as I don't want to wait till my changes are reviewed and finally merged into master but also have the version available from a feature branch to test with it from a different package where it should be used.
  
  I now opted for a manual triggering of the uploading. Not perfect but good enough for now.
Answers: plazmakeks
Answers: CC BY-SA 4.0
Answers: 2022-02-03T23:25:48.160Z
Answers: 2022-02-03T23:25:48.160Z
Answers: kent.io
Body: <p>How should a ci pipeline be set up that publishes a python wheel to a private pypi server?</p>
  <p>Say I have a publish job like this one:</p>
  <pre><code>publish:
    image: $PYTHON_IMAGE
    stage: publish
    before_script:
      - poetry install
      - poetry config repositories.nexus-pypi http://my-nexus.com/pypi-internal/
    script:
      - poetry build -f wheel
      - poetry publish -r nexus-pypi -vvv -u $NEXUS_PYPI_USERNAME -p $NEXUS_PYPI_PASSWORD
  </code></pre>
  <p>With this approach I have a problem with my workflow: Imagine I create a feature branch where I do some changes. I push my changes, pipeline runs and eventually publishes the package to the pypi server. However, once I want to merge that MR it will trigger the pipeline once again and publishing will fail as one cannot reupload packages more than once to pypi.</p>
  <p>This comes along with quite some problems so what I'm asking for is how other do things like that or what best practices are known for this scenario.</p>
  <p>Feel also free to point me to another *overflow if this is not the right place for it.</p>
  
Tags: <continuous-integration><gitlab-ci-runner><python><nexus>
Title: CI pipeline including upload to pypi repo
UserDisplayName: plazmakeks
ThreadText: # CI pipeline including upload to pypi repo
  
  (Asked by: username_0 on 2022-02-03)
  
  How should a ci pipeline be set up that publishes a python wheel to a private pypi server?
  
  Say I have a publish job like this one:
  
  ```
  publish:
    image: $PYTHON_IMAGE
    stage: publish
    before_script:
      - poetry install
      - poetry config repositories.nexus-pypi http://my-nexus.com/pypi-internal/
    script:
      - poetry build -f wheel
      - poetry publish -r nexus-pypi -vvv -u $NEXUS_PYPI_USERNAME -p $NEXUS_PYPI_PASSWORD
  
  ```
  
  With this approach I have a problem with my workflow: Imagine I create a feature branch where I do some changes. I push my changes, pipeline runs and eventually publishes the package to the pypi server. However, once I want to merge that MR it will trigger the pipeline once again and publishing will fail as one cannot reupload packages more than once to pypi.
  
  This comes along with quite some problems so what I'm asking for is how other do things like that or what best practices are known for this scenario.
  
  Feel also free to point me to another \*overflow if this is not the right place for it.
  
  **Tags:** continuous-integration, gitlab-ci-runner, python, nexus
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-02-03. Score: 0
  
  You can use `rules` in gitlab ci to control when you want to stage to be executed: <https://docs.gitlab.com/ee/ci/yaml/index.html#rules>
  
  e.g. set rules to only publish package when branch name is `master`.
  
  You can even use regex for filtering branch name.
  
  Hope it helps.
  
  > **Comments:**
  > **username_0**: This would break my workflow as I don't want to wait till my changes are reviewed and finally merged into master but also have the version available from a feature branch to test with it from a different package where it should be used.  I now opted for a manual triggering of the uploading. Not perfect but good enough for now.  
  
  ---
  
  