feat/release #4

Open
vop wants to merge 37 commits from feat/release into main
Member
No description provided.
vop added 19 commits 2026-09-30 11:37:20 +00:00
add test
All checks were successful
buildOnDev / build (pull_request) Successful in 2m17s
1319bfcaa4
update docs
All checks were successful
buildOnDev / build (pull_request) Successful in 2m12s
e26cdcb0ee
error handling
All checks were successful
buildOnDev / build (pull_request) Successful in 2m12s
22d4949098
some cleanup
All checks were successful
buildOnDev / build (pull_request) Successful in 2m27s
c8d4b59f01
jem requested changes 2026-10-13 14:31:18 +00:00
@ -111,15 +111,15 @@ checksum = "72f5acc6cb2ba439de613abc23857ec3d78374d8ed5ac84e9d11336e87da8649"
[[package]]
name = "cfg-if"
version = "1.0.4"
Owner

Cargo.lock bitte aus dem Repo löschen

Cargo.lock bitte aus dem Repo löschen
vop marked this conversation as resolved
@ -8,2 +8,4 @@
clap_complete = "4.5.60"
rush = { git = "https://repo.prod.meissa.de/meissa/rush.git", tag = "0.1.1" }
rush_task = { git = "https://repo.prod.meissa.de/meissa/rush.git", tag = "0.0.1" }
Owner

gleiches repo, zwei libs ?

gleiches repo, zwei libs ?
vop marked this conversation as resolved
@ -46,4 +48,4 @@
class BuildConfigFile {
<<struct>>
+project_root_path Option~String~
Owner

String?

String?
vop marked this conversation as resolved
@ -50,2 +52,3 @@
+build_dir_name String
+primary_build_file String
+secondary_build_files Vec~String~
Owner

nicht eher [String] ?

nicht eher [String] ?
vop marked this conversation as resolved
@ -154,0 +186,4 @@
git_add_files_to_commit_cmds(&self)
git_commit_cmd(&self, message)
git_push_commit_cmd(&self)
git_push_release_tag(&self)
Owner

git_push_release_tag_cmd ?

git_push_release_tag_cmd ?
vop marked this conversation as resolved
@ -0,0 +40,4 @@
}
}
pub fn new_merge_with_config(
Owner

wozu brauchen wir das hier ?

wozu brauchen wir das hier ?
Author
Member

In den A.C. hatten wir geschrieben, dass die parameter von der cli oder einem config file kommen können, das merge die parameter von der build_config mit dem cli input, wobei der cli input stärker gewichtet ist

In den A.C. hatten wir geschrieben, dass die parameter von der cli oder einem config file kommen können, das merge die parameter von der build_config mit dem cli input, wobei der cli input stärker gewichtet ist
Author
Member

Bzw. das war die Idee aber jetzt geht das auch :D

Bzw. das war die Idee aber jetzt geht das auch :D
Owner

Ich dachte da eher an ein entweder oder und nicht an gemischte quellen ... lass uns das nochmals diskutieren.

Ich dachte da eher an ein entweder oder und nicht an gemischte quellen ... lass uns das nochmals diskutieren.
jem marked this conversation as resolved
@ -0,0 +224,4 @@
//then
assert_eq!(patch.get_next_version().unwrap(), Version::new(1, 2, 3));
}
Owner

Der interessante Fall ist:

Snapshot-version from x und zwar für alle filetypen.

Der Test dafür fehlt.

Der interessante Fall ist: Snapshot-version from x und zwar für alle filetypen. Der Test dafür fehlt.
jem marked this conversation as resolved
@ -0,0 +107,4 @@
major: version.major,
minor: version.minor,
patch: version.patch + 1,
pre: Prerelease::new("SNAPSHOT").unwrap(),
Owner

Der String hängt vom release type ab ...
z.b. dev für python & image ...

Der String hängt vom release type ab ... z.b. dev für python & image ...
vop marked this conversation as resolved
@ -0,0 +119,4 @@
))
}
pub fn get_next_snapshot_version(&self) -> Result<Version, ApplicationError> {
Owner

get_next_prerelease_version

get_next_prerelease_version
vop marked this conversation as resolved
@ -0,0 +67,4 @@
impl BuildType {
pub const GRADLE_GROOVY: BuildType = BuildType {
default_filename: "build.gradle",
Owner

sind die filenames hier fix vorgegeben oder nur die datei endung ?

sind die filenames hier fix vorgegeben oder nur die datei endung ?
Author
Member

Die sind für das implizite finden der primary build file, bei explizit angegeben files wird die nur Endung verglichen um den build type zu bestimmen

Die sind für das implizite finden der primary build file, bei explizit angegeben files wird die nur Endung verglichen um den build type zu bestimmen
Owner

implizit hört sich nach einem Fass ohne boden an ... lass uns hier mal zusammen draufschauen und die Folgekosten überlegen.

implizit hört sich nach einem Fass ohne boden an ... lass uns hier mal zusammen draufschauen und die Folgekosten überlegen.
vop marked this conversation as resolved
@ -0,0 +152,4 @@
use crate::domain::release::{BuildFile, BuildType};
#[test]
fn test_get_version_string() {
Owner

Test für jeden build type mit get_version_from and mit replace_version ...

Test für jeden build type mit get_version_from and mit replace_version ...
vop marked this conversation as resolved
@ -118,6 +118,22 @@ impl From<String> for ApplicationError {
}
}
impl From<regex::Error> for ApplicationError {
Owner

Die Fehler hier habe nix mit validation zu tun => in eine andere datei!

Die Fehler hier habe nix mit validation zu tun => in eine andere datei!
vop marked this conversation as resolved
@ -0,0 +15,4 @@
primary_file.path
));
let secondary_files = if !release_input.secondary_build_files.is_empty() {
Owner

warum diese if ?
Release input kann ja immer einen vektor von haben - im Empty-Fall ist der Vektor dann eben auch empty ....

warum diese if ? Release input kann ja immer einen vektor von haben - im Empty-Fall ist der Vektor dann eben auch empty ....
vop marked this conversation as resolved
@ -0,0 +39,4 @@
}
fn find_and_load_build_file(file_path: &String) -> Result<BuildFile, ApplicationError> {
if file_path.is_empty() {
Owner

alles implizite bitte in die domaine schieben.
Hier in der infrastruktur keine unnötige logik mehr sondern nur noch stright forward operations.

alles implizite bitte in die domaine schieben. Hier in der infrastruktur keine unnötige logik mehr sondern nur noch stright forward operations.
vop marked this conversation as resolved
@ -0,0 +81,4 @@
}
}
pub fn save_file_content(build_file: &BuildFile, content: &str) -> Result<(), ApplicationError> {
Owner

die pub-schnittstelle bitte äquivalent zu - symmetrie!

pub fn load_release_run_time(
			    release_input: &ReleaseInput,
			)
die pub-schnittstelle bitte äquivalent zu - symmetrie! ``` pub fn load_release_run_time( release_input: &ReleaseInput, ) ```
vop marked this conversation as resolved
@ -0,0 +96,4 @@
}
}
pub fn write_version_to_files(
Owner

Warum brauchen wir das ? imho sollte die infra hier nur 2 pub functions haben !
Alles andere kann hoch in den service wandern.

Warum brauchen wir das ? imho sollte die infra hier nur 2 pub functions haben ! Alles andere kann hoch in den service wandern.
vop marked this conversation as resolved
@ -0,0 +111,4 @@
Ok(())
}
fn write_version_to_file(
Owner

s.o.

Version ersetzen sollte in der Domaine passieren, dort können wir das ordentlich testen.

  1. Runtime aus der infra lesen
  2. version auslesen und ersetzen -> verändert das Runtime-Struct (oder macht ein neues)
  3. Verändertes Runtime-Struct schreiben
s.o. Version ersetzen sollte in der Domaine passieren, dort können wir das ordentlich testen. 1. Runtime aus der infra lesen 2. version auslesen und ersetzen -> verändert das Runtime-Struct (oder macht ein neues) 3. Verändertes Runtime-Struct schreiben
vop marked this conversation as resolved
@ -0,0 +123,4 @@
Ok(())
}
pub fn assert_result_with_info<T>(
Owner

Wozu brauchen wir das ?

Wozu brauchen wir das ?
Author
Member

Ansgar hatte sich gewünscht, dass am ende des Programms eine Zusammenfassung gezeigt wird, ob wichtige schritte geklappt haben oder nicht, und ich wollte nicht dauernd im code match {ok(), err()} schreiben

Ansgar hatte sich gewünscht, dass am ende des Programms eine Zusammenfassung gezeigt wird, ob wichtige schritte geklappt haben oder nicht, und ich wollte nicht dauernd im code match {ok(), err()} schreiben
vop marked this conversation as resolved
Cargo.lock gelöscht
All checks were successful
buildOnDev / build (pull_request) Successful in 5m4s
0edfcdbb64
wip: rework
Some checks failed
buildOnDev / build (pull_request) Failing after 2m8s
ea19b6075e
move stuff up
Some checks failed
buildOnDev / build (pull_request) Failing after 2m13s
1fdf3c9971
add file extension
All checks were successful
buildOnDev / build (pull_request) Successful in 2m8s
0bbead55df
add filetypes to test
All checks were successful
buildOnDev / build (pull_request) Successful in 2m8s
e55328f4a8
wip: add more tests
Some checks failed
buildOnDev / build (pull_request) Failing after 1m59s
c7e28bc6da
Some checks failed
buildOnDev / build (pull_request) Failing after 1m59s
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feat/release:feat/release
git switch feat/release

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff feat/release
git switch feat/release
git rebase main
git switch main
git merge --ff-only feat/release
git switch feat/release
git rebase main
git switch main
git merge --no-ff feat/release
git switch main
git merge --squash feat/release
git switch main
git merge --ff-only feat/release
git switch main
git merge feat/release
git push origin main
Sign in to join this conversation.
No reviewers
jem
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
meissa/dda-build-rust!4
No description provided.