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

[Potherca]

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^™️ to automate these changes.

Some thoughts:

• If we are going to automate changes, we might as well remove all non-deployed files (leaving only C4.puml, C4_Component.puml, C4_Container.puml, C4_Context.puml, C4_Deployment.puml, C4_Dynamic.puml, and INFO files)
• We should probably use a GitHub action, triggered by a release / tag
• The automation could also automatically open an MR at https://github.com/plantuml/plantuml-stdlib

Some questions:

• What would be the best mechanism for holding these changes? I separate deploy branch? A detached/orphan branch? A git subtree of plantuml-stdlib? A separate folder? Something else entirely?
• Is it wise to open the MR automatically? Or should it be manual?
• Do we need anything from or do we need to communicate anything with the official plantuml-stdlib repo?
• Does anyone else have any thoughts/feelings on this?

[kirchsth]

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]

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]

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]

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

[Potherca]

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]

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]

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]

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]

No, looks good to me. Closing.