1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
|
%global _empty_manifest_terminate_build 0
Name: python-octomy-common
Version: 1.0.46
Release: 1
Summary: OctoMY common
License: GPL-3 LGPL-3 MIT
URL: https://gitlab.com/octomy/common
Source0: https://mirrors.nju.edu.cn/pypi/web/packages/9d/cb/c0e843a9b3f6ef30f046fa79f703b65d2df87cae8146fdccb4e4da6415ce/octomy-common-1.0.46.tar.gz
BuildArch: noarch
%description
[](https://gitlab.com/octomy/common/-/commits/production)
# About common
<img src="https://gitlab.com/octomy/common/-/raw/production/design/logo-1024.png" width="20%"/>
This pypi package contains common files for octomy python projects
- Common is [available on gitlab](https://gitlab.com/octomy/common).
- Common is [available in PyPI](https://pypi.org/project/common/).
```shell
# Clone git repository
git clone git@gitlab.com:octomy/common.git
```
```shell
# Install package into your current Python environment
pip install octomy-common
```
# Versioning
In this section the versioning scheme used for all octomy codebases will be explained.
First of, we strive to follow [semver](https://semver.org/) as far as possible, so any details pertaining to the actual version numbers themselves is better explained in the semver spec. This documentation refers to how we store, change and update the version number in the project itself, and how that version number is propagated from source to build artifacts such as PyPi packages, Docker images and more.
## Source of version number
The source of the version number shall be a one line, plain-text file in the root of the project simply called [VERSION](VERSION)
This should contain the full version number on semver format and nothing else. Example versions are:
* 0.0.1
* 0.1.3
* 1.0.0
* 2.2.12
> NOTE: There should not be any prefixes or postfixes in this version. No "rc", "beta" as this is handled by the logic as described below.
## git branches
We will operate with 3 protected git branches. The rules that govern them are as follows:
| Branch | Description |
| --------------- |--------------------------|
| production | This corresponds to what is in production right now. Using CI/CD, anything merged to this branch will immediately be built and deployed in production, replacing whatever was in production before |
| beta | This corresponds to what is in the beta environment right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the beta environment, replacing whatever was in that environment before. Beta means an almost ready "next version" that is ready to preview for a selection of customers. |
| stage-_XXX_ | This corresponds to what is in the stage environment labelled _XXX_ right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the stage-_XXX_ environment, replacing whatever was in that environment before. Please note that the _XXX_ could be any string, you may have several stage environments labelled as you see fit. Typically you will have a stage set up for a private presentation to a select client, or for internal testing. |
| * | Any other branch is considered unprotected and may be built and tested using CI/CD, but will not be considered for any automatic deployment. When built and deployed manually, these branches will have `test-`prepended to them for easy identification. |
## PyPi packages
PyPi package names are on the form `project_name`-`version` The branch name is omitted entirely and it is expected that PyPi packages are deployed only for the production branch.
## Docker images
Docker images are named `project_name` and tagged with `branch_name`-`version`. The branch name is omitted for "production" giving simply `version` in that case. Further, any branch name starting with `stage-` will have the `stage-` part removed. And finally, any branch that is not production, beta or stage-X will have `test-`prepended to the branch name itself, so it becomes `version`-test-`branch_name`.
## Examples
* Example project name: __my_project__
* Example version: __1.2.3__
* Example stage name: __my_presentation__
| git branch name | Docker image | PyPi package |
| --------------- |--------------------------| -------------------------|
| `production` | my_project:_1.2.3_ | my_project-_1.2.3_ |
| `beta` | my_project:_1.2.3_-`beta` | N/A |
| `stage-my_presentation` | my_project:_1.2.3_-`my_presentation` | N/A |
| `silly_branch` | my_project:_1.2.3_-__test__-`silly_branch` | N/A |
## Implementation
To maintain this versioning, we depend on a few tools for the logic:
1. bash
2. make
3. setup.py (Python)
Each octomy project will have a [Makefile](Makefile) in the root of the project that has targets for building and pushing pypi and/or Docker images. It [specifies bash as the shell](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html) to use, and use [bash string manipulation and conditions](https://www.gnu.org/software/bash/manual/bash.html) to generate the correct version string following the rules above for Docker tags. Further, the rules are implemented as a function in setup.py to satisfy the rules when building pypi package.
The Makefile targets are named as follows:
| make target | Description |
| --------------- |----------------------------------------------------------------|
| docker-build | Build the docker image with correct version tags |
| docker-push | Push the docker image with correct version tags to registry |
| pypi-build | Build the pypi package with correct version |
| pypi-push | Push the pypi package with correct version to PyPi repository. NOTE: Should only be called for production branch |
## Example implementation
This octomy-common project will follow the rules above and will contain the Makefile targets that can be used as a reference for other projects.
%package -n python3-octomy-common
Summary: OctoMY common
Provides: python-octomy-common
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-octomy-common
[](https://gitlab.com/octomy/common/-/commits/production)
# About common
<img src="https://gitlab.com/octomy/common/-/raw/production/design/logo-1024.png" width="20%"/>
This pypi package contains common files for octomy python projects
- Common is [available on gitlab](https://gitlab.com/octomy/common).
- Common is [available in PyPI](https://pypi.org/project/common/).
```shell
# Clone git repository
git clone git@gitlab.com:octomy/common.git
```
```shell
# Install package into your current Python environment
pip install octomy-common
```
# Versioning
In this section the versioning scheme used for all octomy codebases will be explained.
First of, we strive to follow [semver](https://semver.org/) as far as possible, so any details pertaining to the actual version numbers themselves is better explained in the semver spec. This documentation refers to how we store, change and update the version number in the project itself, and how that version number is propagated from source to build artifacts such as PyPi packages, Docker images and more.
## Source of version number
The source of the version number shall be a one line, plain-text file in the root of the project simply called [VERSION](VERSION)
This should contain the full version number on semver format and nothing else. Example versions are:
* 0.0.1
* 0.1.3
* 1.0.0
* 2.2.12
> NOTE: There should not be any prefixes or postfixes in this version. No "rc", "beta" as this is handled by the logic as described below.
## git branches
We will operate with 3 protected git branches. The rules that govern them are as follows:
| Branch | Description |
| --------------- |--------------------------|
| production | This corresponds to what is in production right now. Using CI/CD, anything merged to this branch will immediately be built and deployed in production, replacing whatever was in production before |
| beta | This corresponds to what is in the beta environment right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the beta environment, replacing whatever was in that environment before. Beta means an almost ready "next version" that is ready to preview for a selection of customers. |
| stage-_XXX_ | This corresponds to what is in the stage environment labelled _XXX_ right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the stage-_XXX_ environment, replacing whatever was in that environment before. Please note that the _XXX_ could be any string, you may have several stage environments labelled as you see fit. Typically you will have a stage set up for a private presentation to a select client, or for internal testing. |
| * | Any other branch is considered unprotected and may be built and tested using CI/CD, but will not be considered for any automatic deployment. When built and deployed manually, these branches will have `test-`prepended to them for easy identification. |
## PyPi packages
PyPi package names are on the form `project_name`-`version` The branch name is omitted entirely and it is expected that PyPi packages are deployed only for the production branch.
## Docker images
Docker images are named `project_name` and tagged with `branch_name`-`version`. The branch name is omitted for "production" giving simply `version` in that case. Further, any branch name starting with `stage-` will have the `stage-` part removed. And finally, any branch that is not production, beta or stage-X will have `test-`prepended to the branch name itself, so it becomes `version`-test-`branch_name`.
## Examples
* Example project name: __my_project__
* Example version: __1.2.3__
* Example stage name: __my_presentation__
| git branch name | Docker image | PyPi package |
| --------------- |--------------------------| -------------------------|
| `production` | my_project:_1.2.3_ | my_project-_1.2.3_ |
| `beta` | my_project:_1.2.3_-`beta` | N/A |
| `stage-my_presentation` | my_project:_1.2.3_-`my_presentation` | N/A |
| `silly_branch` | my_project:_1.2.3_-__test__-`silly_branch` | N/A |
## Implementation
To maintain this versioning, we depend on a few tools for the logic:
1. bash
2. make
3. setup.py (Python)
Each octomy project will have a [Makefile](Makefile) in the root of the project that has targets for building and pushing pypi and/or Docker images. It [specifies bash as the shell](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html) to use, and use [bash string manipulation and conditions](https://www.gnu.org/software/bash/manual/bash.html) to generate the correct version string following the rules above for Docker tags. Further, the rules are implemented as a function in setup.py to satisfy the rules when building pypi package.
The Makefile targets are named as follows:
| make target | Description |
| --------------- |----------------------------------------------------------------|
| docker-build | Build the docker image with correct version tags |
| docker-push | Push the docker image with correct version tags to registry |
| pypi-build | Build the pypi package with correct version |
| pypi-push | Push the pypi package with correct version to PyPi repository. NOTE: Should only be called for production branch |
## Example implementation
This octomy-common project will follow the rules above and will contain the Makefile targets that can be used as a reference for other projects.
%package help
Summary: Development documents and examples for octomy-common
Provides: python3-octomy-common-doc
%description help
[](https://gitlab.com/octomy/common/-/commits/production)
# About common
<img src="https://gitlab.com/octomy/common/-/raw/production/design/logo-1024.png" width="20%"/>
This pypi package contains common files for octomy python projects
- Common is [available on gitlab](https://gitlab.com/octomy/common).
- Common is [available in PyPI](https://pypi.org/project/common/).
```shell
# Clone git repository
git clone git@gitlab.com:octomy/common.git
```
```shell
# Install package into your current Python environment
pip install octomy-common
```
# Versioning
In this section the versioning scheme used for all octomy codebases will be explained.
First of, we strive to follow [semver](https://semver.org/) as far as possible, so any details pertaining to the actual version numbers themselves is better explained in the semver spec. This documentation refers to how we store, change and update the version number in the project itself, and how that version number is propagated from source to build artifacts such as PyPi packages, Docker images and more.
## Source of version number
The source of the version number shall be a one line, plain-text file in the root of the project simply called [VERSION](VERSION)
This should contain the full version number on semver format and nothing else. Example versions are:
* 0.0.1
* 0.1.3
* 1.0.0
* 2.2.12
> NOTE: There should not be any prefixes or postfixes in this version. No "rc", "beta" as this is handled by the logic as described below.
## git branches
We will operate with 3 protected git branches. The rules that govern them are as follows:
| Branch | Description |
| --------------- |--------------------------|
| production | This corresponds to what is in production right now. Using CI/CD, anything merged to this branch will immediately be built and deployed in production, replacing whatever was in production before |
| beta | This corresponds to what is in the beta environment right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the beta environment, replacing whatever was in that environment before. Beta means an almost ready "next version" that is ready to preview for a selection of customers. |
| stage-_XXX_ | This corresponds to what is in the stage environment labelled _XXX_ right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the stage-_XXX_ environment, replacing whatever was in that environment before. Please note that the _XXX_ could be any string, you may have several stage environments labelled as you see fit. Typically you will have a stage set up for a private presentation to a select client, or for internal testing. |
| * | Any other branch is considered unprotected and may be built and tested using CI/CD, but will not be considered for any automatic deployment. When built and deployed manually, these branches will have `test-`prepended to them for easy identification. |
## PyPi packages
PyPi package names are on the form `project_name`-`version` The branch name is omitted entirely and it is expected that PyPi packages are deployed only for the production branch.
## Docker images
Docker images are named `project_name` and tagged with `branch_name`-`version`. The branch name is omitted for "production" giving simply `version` in that case. Further, any branch name starting with `stage-` will have the `stage-` part removed. And finally, any branch that is not production, beta or stage-X will have `test-`prepended to the branch name itself, so it becomes `version`-test-`branch_name`.
## Examples
* Example project name: __my_project__
* Example version: __1.2.3__
* Example stage name: __my_presentation__
| git branch name | Docker image | PyPi package |
| --------------- |--------------------------| -------------------------|
| `production` | my_project:_1.2.3_ | my_project-_1.2.3_ |
| `beta` | my_project:_1.2.3_-`beta` | N/A |
| `stage-my_presentation` | my_project:_1.2.3_-`my_presentation` | N/A |
| `silly_branch` | my_project:_1.2.3_-__test__-`silly_branch` | N/A |
## Implementation
To maintain this versioning, we depend on a few tools for the logic:
1. bash
2. make
3. setup.py (Python)
Each octomy project will have a [Makefile](Makefile) in the root of the project that has targets for building and pushing pypi and/or Docker images. It [specifies bash as the shell](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html) to use, and use [bash string manipulation and conditions](https://www.gnu.org/software/bash/manual/bash.html) to generate the correct version string following the rules above for Docker tags. Further, the rules are implemented as a function in setup.py to satisfy the rules when building pypi package.
The Makefile targets are named as follows:
| make target | Description |
| --------------- |----------------------------------------------------------------|
| docker-build | Build the docker image with correct version tags |
| docker-push | Push the docker image with correct version tags to registry |
| pypi-build | Build the pypi package with correct version |
| pypi-push | Push the pypi package with correct version to PyPi repository. NOTE: Should only be called for production branch |
## Example implementation
This octomy-common project will follow the rules above and will contain the Makefile targets that can be used as a reference for other projects.
%prep
%autosetup -n octomy-common-1.0.46
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-octomy-common -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Mon May 29 2023 Python_Bot <Python_Bot@openeuler.org> - 1.0.46-1
- Package Spec generated
|
