search

plantuml-stdlib / C4-PlantUML

C4-PlantUML combines the benefits of PlantUML and the C4 model for providing a simple way of describing and communicate software architectures
MIT License
6.45k stars 1.1k forks source link

Automate creating a deployable state for the official PlantUML std-lib? #148

Closed Potherca closed 1 year ago

Potherca commented 3 years ago

Currently, there is one major difference between this repo and the code merged into the official plantuml-stdlib.

We have a dynamic include (i.e. an URL is used, meaning the content at the URL could be changed between requests):

!if %variable_exists("RELATIVE_INCLUDE")
  !include %get_variable_value("RELATIVE_INCLUDE")/C4_Container.puml
!else
  !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
!endif

But the official repo uses a static include (i.e. content present in the repo itself):

!include <C4/C4_Container>

In order to make it easier to for future upgrades, and to prevent manually having to change code, I propose we do something:tm: to automate these changes.

Some thoughts:

Some questions:

kirchsth commented 3 years ago

Hi @Potherca, I "found" the plantuml-stdlib/update-stdlib.sh repository.

Wouldn't it be a good/logical approach a) integrate all relevant automatic changes/updates/check-in in the update_sources.sh script b) and if you want no "C4-PlantUML" specific logic in "update-stdlib.sh" repository you could add an "update-stdlib" folder to "C4-PlantUML" which is called by the update-stdlib.sh scripts.

BR Helmut

Potherca commented 3 years ago

One of my long-term goals in creating the plantuml-stdlib organization and motivating projects to migrate here is to automate update and release processes for all repos.

I'm still thinking about what the best way to do this is. (For instance one central place that updates "all teh thingz", or a distributed approach where each project has their own update logic).

Currently, I'm leaning more towards a centralized approach, as that would also allow updating repos that are not under out control.

That means project-specific logic is expected to be added (eventually) to any update logic we create.

Another thing I'm still wondering about is whether to run updated from projects (via a GitHub Action, for instance), or if it should be push-button (i.e. manually triggered), or triggered by an external "something" (for instance updates in the main PlantUML repo).

At this point, all input is welcome...

kirchsth commented 3 years ago

Hi @Potherca, with PR #182 I added more work for you (automatic update of the correct version number) but I think with the new version functions it would be simpler to find version conflicts, missing functions and other problemes. BR Hemut

kirchsth commented 3 years ago

Hi @Potherca, I think we schould create a new v2.4.0. Did/do you have some time for automation? BR Helmut

Potherca commented 3 years ago

I've not had time yet. We might want to bump this ticket to v2.5 while I run another manual deploy/release of the current changes.

kirchsth commented 1 year ago

Hi @Potherca,

I add in the feature/148 branch a short description and a python script that all includes and other topics can be update. Maybe you can use it in your automation process ...

BR Helmut

kirchsth commented 1 year ago

Hi @Potherca,

I stored an updated version of the script in plantuml-stdlib/C4-PlantUML/275-improving-the-release-process branch in commit

therefore I delete the outdated feature/148 branch that we have all on one place

BR Helmut

kirchsth commented 1 year ago

Hi @Potherca,

275 contains already the python script, which prepares the plantuml-stdlib (local on my machine it copies the themes files too),

Therefore I think we can close this issue. Or do you plan something different in this story?

BR Helmut

Potherca commented 1 year ago

No, looks good to me. Closing.