PyPi configuration in Nexus3
There are 5 PyPi repositories present in Nexus3:
Pypi (proxy) - This repository is used to proxy https://pypi.python.org/
https://nexus3.onap.org/repository/PyPi/
Pypi.public (group) - This group consolidates PyPi.release and PyPi. This group should be accessed for reading/pulling purposes.
https://nexus3.onap.org/repository/PyPi.public/
Pypi.release (hosted) - This repository hosts our official releases. This repo does not allow re-deployment
https://nexus3.onap.org/repository/PyPi.release/
Pypi.snapshot (hosted) - Used to host our snapshots meanwhile the release candidate is being worked on. This repo allows re-deployment.
https://nexus3.onap.org/repository/PyPi.snapshot/
Pypi.staging (hosted) - Used for our daily/staging non official publications. This repo allows re-deployment.
https://nexus3.onap.org/repository/PyPi.staging/
PyPi configuration in Jenkins and JJB
Projects can leverage this set of templates when they are a python project that needs to upload python packages to a PyPi repository.
...
- {project-name}-python-staging-{stream}
- {project-name}-python-release-{stream}
- {project-name}-{subproject}-python-staging-{stream}
- {project-name}-{subproject}-python-release-{stream}
General Job Information
The "staging" jobs will trigger a Jenkins job that builds the python package and pushes the package to a staging repo located here https://nexus3.onap.org/repository/PyPi.staging/.
...
- project-name
- stream
- tox-dir (optional, default: '')
- tox-envs (optional, default: '')
- python-version
Note | ||
---|---|---|
| ||
tox-dir typically only need to be specified for subprojects. You can specify it though if your tox.ini is somewhere other than the root of your project. tox-envs are set to blank always so they do not overwrite your tox.ini; Setting them blank gives the option to set them if you manually kick off a job for troubleshooting purposes though. |
Python projects with a subproject
Some projects have a structure where one repo contains several projects. LF has built templates to support them as well; you will use
these projectstemplates:
- {project-name}-{subproject}-python-staging-{stream}
- {project-name}-{subproject}-python-release-{stream}
...
Here is a concrete example of how to set up pypi jobs for a project with subprojects using dcaegen2/utils.
...
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
--- |
...
- project: |
...
name: dcaegen2-utils |
...
project-name: 'dcaegen2-utils' |
...
python-version: |
...
subproject:
- 'dcaeapplib':
tox-dir: dcaeapplib/
tox-envs: ''
...
python3 project: 'dcaegen2/utils' stream: - 'master': branch: 'master' mvn-settings: 'dcaegen2-utils-settings' # due to a strange macro / variable translation problem this needs # to be passed as a string block to properly get the properties # correctly defined in the job maven-deploy-properties: | deployAtEnd=true files: '**' archive-artifacts: '' subproject: - 'dcaeapplib': tox-dir: dcaeapplib/ tox-envs: '' - 'onap-dcae-dbs-docker-client': |
...
tox-dir: onap-dcae-dbs-docker-client/ |
...
tox-envs: '' |
...
- 'onap-dcae-dcaepolicy-lib': |
...
tox-dir: onap-dcae-dcaepolicy-lib/ |
...
tox-envs: '' |
...
- 'python-discovery-client': |
...
tox-dir: python-discovery-client/ |
...
tox-envs: '' |
...
- 'python-dockering': |
...
tox-dir: python-dockering/ |
...
tox-envs: '' |
...
jobs:
- gerrit-maven-clm
- '{project-name}-{stream}-verify-java'
...
jobs: - '{project-name}-{ |
...
- '{project-name}-{stream}-release-version-java-daily'
...
subproject}-python-staging-{stream}' |
...
- '{project-name}-{subproject}-python-release-{stream}' |
...
project: 'dcaegen2/utils'
stream:
- 'master':
branch: 'master'
mvn-settings: 'dcaegen2-utils-settings'
# due to a strange macro / variable translation problem this needs
# to be passed as a string block to properly get the properties
# correctly defined in the job
maven-deploy-properties: |
deployAtEnd=true
files: '**'
archive-artifacts: ''
...
build-node: 'ubuntu1604-docker-8c-8g' |
...
...
Info |
---|
Note that the use of these templates implies a workflow where the staging artifact will be overwritten on each merge event. We are working on features that will allow immutable staging as well. |
Related articles
Filter by label (Content by label) | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Page Properties | ||
---|---|---|
| ||
|
...