Skip to content

Commit 0e2e7c6

Browse files
authored
Fix annoying pipeline 7 (#160)
* Take 7 on attempting lib deploys * Structuring readme and returning types deploy
1 parent 2c1a416 commit 0e2e7c6

File tree

4 files changed

+83
-58
lines changed

4 files changed

+83
-58
lines changed

.github/workflows/rust_tag_and_deploy.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ jobs:
7171
- name: Deploy using tag
7272
working-directory: ./ahnlich
7373
run: |
74-
# cargo publish -p ahnlich_types --token '${{secrets.CARGO_TOKEN}}'
74+
cargo publish -p ahnlich_types --token '${{secrets.CARGO_TOKEN}}'
7575
# Removing dev dependencies as those use * and are only locally available
7676
sed -i '/^\[dev-dependencies\]/,/^\[/{//!d; /^\[dev-dependencies\]/s/.*/ /}' client/Cargo.toml
7777
cargo publish --allow-dirty -p ahnlich_client_rs --token '${{secrets.CARGO_TOKEN}}'

README.md

Lines changed: 0 additions & 57 deletions
Original file line numberDiff line numberDiff line change
@@ -61,60 +61,3 @@ The DB can be used without the AI proxy for more fine grained control of the gen
6161
### Contributing
6262

6363
View [contribution guide](CONTRIBUTING.md)
64-
65-
### Version Format
66-
67-
`<TYPE>/<NAME>/<VERSION_NUMBER>`
68-
69-
Where:
70-
- TYPE: Bin, Client,
71-
- NAME: AI, DB, PY, RS
72-
- VERSION_NUMBER: Semver
73-
74-
75-
### How Deployments and Releases Work
76-
77-
Ahnlich maintains two separate versioning systems: **Protocol Versions** and **Client Versions**. Understanding how these interact is key to managing releases across binaries, libraries, and Docker images.
78-
79-
#### Protocol and Client Versioning
80-
- The **Protocol Version** represents changes to the underlying communication standard between different Ahnlich components. Major bump to this version can introduce breaking changes, meaning requests made by outdated clients will be rejected.
81-
- The **Client Version** tracks updates to the client libraries. These are versioned separately but are often synchronized with protocol updates to ensure compatibility.
82-
83-
##### Bumping Protocol Versions
84-
- To bump both the Protocol and Client versions simultaneously, use the following command:
85-
```bash
86-
make bump-protocol-version BUMP_RULE=[major, minor, patch]
87-
```
88-
This will trigger deployments for all relevant binaries (like AI, CLI, and DB) as well as client libraries.
89-
- Major changes to the Protocol Version may involve breaking changes, so ahnlich AI or DB rejects a connection when the major version don't match.
90-
91-
##### Bumping Individual Package/Crate Versions
92-
- The Makefile contains additional commands for selectively bumping versions of crate or lib within the workspace.
93-
94-
#### Releasing New Binaries (AI, CLI, DB), Images and Client Libs
95-
When deploying new binaries, the updated versions are pushed to their respective Artifactory repositories. The workflow is as follows:
96-
97-
##### Binaries and Docker Images
98-
1. **Bump the Protocol Version**: Use the appropriate Makefile commands to bump versions for AI, CLI, or DB binaries or client Libs.
99-
100-
2. Submit a PR to main
101-
3. Once merged, Create a tag using the the ahnlich tag format
102-
4. Create a Release from tag which triggers building of binaries and docker images
103-
104-
##### Client Libraries (Example Python)
105-
106-
- Update the `MSG_TAG` file with a new tag message.
107-
- From a feature branch, bump the version using:
108-
```bash
109-
make bump-py-client BUMP_RULE=[major, minor, patch]
110-
```
111-
or
112-
```bash
113-
poetry run bumpversion [major, minor, patch]
114-
```
115-
- Open a PR to Main
116-
- Once merged, this automatically creates a tags if a change to the version file is detected and deploys the lib to it's artifactory.
117-
118-
119-
120-

ahnlich/types/README.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
## Ahnlich Types
2+
3+
Types used by the ahnlich rust client
4+
5+
6+
[![Crates.io](https://img.shields.io/crates/v/ahnlich_types.svg)](https://crates.io/crates/ahnlich_types)
7+
[![Documentation](https://docs.rs/ahnlich_types/badge.svg)](https://docs.rs/ahnlich_types/)
8+
[![Ahnlich TestSuite](https://github.com/deven96/ahnlich/actions/workflows/test.yml/badge.svg)](https://github.com/deven96/ahnlich/actions/workflows/test.yml)
9+
[![Ahnlich Types Tag and Deploy](https://github.com/deven96/ahnlich/actions/workflows/rust_tag_and_deploy.yml/badge.svg)](https://github.com/deven96/ahnlich/actions/workflows/rust_tag_and_deploy.yml)
10+
11+
## Usage Overview
12+
13+
The following topics are covered:
14+
* [Installation](#installation)
15+
* [Change Log](#change-log)
16+
17+
## Installation
18+
19+
```bash
20+
cargo add ahnlich_types
21+
```
22+
23+
## Change Log
24+
25+
| Version| Description |
26+
| -------|:-------------:|
27+
| 0.0.0 | Adding types for version 0.0.0 |
28+
29+

docs/libgen.md

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,3 +22,56 @@ Available languages are:
2222
In order to communicate effectively with the ahnlich db, you would have to extend the bincode serialization protocol automatically provided by `serde_generate`.
2323
Your message(in bytes) should be serialized and deserialized in the following format => `AHNLICH_HEADERS` + `VERSION` + `QUERY/SERVER_RESPONSE`. Bytes are `Little Endian`.
2424

25+
### Version Format
26+
27+
`<TYPE>/<NAME>/<VERSION_NUMBER>`
28+
29+
Where:
30+
- TYPE: Bin, Client,
31+
- NAME: AI, DB, PY, RS
32+
- VERSION_NUMBER: Semver
33+
34+
35+
### How Deployments and Releases Work
36+
37+
Ahnlich maintains two separate versioning systems: **Protocol Versions** and **Client Versions**. Understanding how these interact is key to managing releases across binaries, libraries, and Docker images.
38+
39+
#### Protocol and Client Versioning
40+
- The **Protocol Version** represents changes to the underlying communication standard between different Ahnlich components. Major bump to this version can introduce breaking changes, meaning requests made by outdated clients will be rejected.
41+
- The **Client Version** tracks updates to the client libraries. These are versioned separately but are often synchronized with protocol updates to ensure compatibility.
42+
43+
##### Bumping Protocol Versions
44+
- To bump both the Protocol and Client versions simultaneously, use the following command:
45+
```bash
46+
make bump-protocol-version BUMP_RULE=[major, minor, patch]
47+
```
48+
This will trigger deployments for all relevant binaries (like AI, CLI, and DB) as well as client libraries.
49+
- Major changes to the Protocol Version may involve breaking changes, so ahnlich AI or DB rejects a connection when the major version don't match.
50+
51+
##### Bumping Individual Package/Crate Versions
52+
- The Makefile contains additional commands for selectively bumping versions of crate or lib within the workspace.
53+
54+
#### Releasing New Binaries (AI, CLI, DB), Images and Client Libs
55+
When deploying new binaries, the updated versions are pushed to their respective Artifactory repositories. The workflow is as follows:
56+
57+
##### Binaries and Docker Images
58+
1. **Bump the Protocol Version**: Use the appropriate Makefile commands to bump versions for AI, CLI, or DB binaries or client Libs.
59+
60+
2. Submit a PR to main
61+
3. Once merged, Create a tag using the the ahnlich tag format
62+
4. Create a Release from tag which triggers building of binaries and docker images
63+
64+
##### Client Libraries (Example Python)
65+
66+
- Update the `MSG_TAG` file with a new tag message.
67+
- From a feature branch, bump the version using:
68+
```bash
69+
make bump-py-client BUMP_RULE=[major, minor, patch]
70+
```
71+
or
72+
```bash
73+
poetry run bumpversion [major, minor, patch]
74+
```
75+
- Open a PR to Main
76+
- Once merged, this automatically creates a tags if a change to the version file is detected and deploys the lib to it's artifactory.
77+

0 commit comments

Comments
 (0)