My Workflow
How I chose this repository
I searched for open source projects that would be interesting, and I came across a project in its early development stages (6 months since its first commit). It caught my attention because it provides support for developing text-based interfaces using C++ 20 and at the time its building actions could be improved.
gdt050579
/
AppCUI
AppCUI is a cross-platform TUI (Text User Interface) framework designed to allow quick creation of both TUI Application and TUI Games. AppCUI is heavily based on C++20 standards and offers a multitude of widgets such as windows, buttons, checkboxes, radioboxes, comboboxes, listviews, treeviews, tab controls, image previewers, and many more.
AppCUI
This logo is an application made with AppCUI.
General description
AppCUI is a cross-platform TUI builder. The users of this library can construct an interface using its basic building blocks such as: Window, Button, Label, etc.
Generally speaking, the library allows to build a virtual desktop, with multiple windows and extensible components.
The first example is ListView, an application to showcase US states and their basic information like Population, Capital. The user is greeted with an initial window with list view options, like whether the columns are sortable or whether the column separators are visible, after that, a button is pressed to spawn another window with a list view, showcasing the US states.
The library displays the whole spectre of ASCII (and ASCII extended, via Code Page 437) characters, but also a wide range of UTF16 characters.
In this example…
AppCUI
AppCUI is a cross-platform text-based user interface. It offers support for building complex interfaces using basic bulding blocks, such as Window, Button, Label, etc.
You can find more here. The license is permissive.
DIY Deployments
The first action I integrated into the repository was CodeQL analysis.
Since the project doesn't have a release method right now, I decided to propose a solution for automatically uploading the binaries when the build is done when a tag is submitted having a specific format vMajorVers.MinorVers.PatchVersion.
This is only the stepping stone because the real automated workflow would now require (in my opinion) any interaction from the user, and it would automatically increase the version number.
When there are found merges to the release branch → it triggers an PatchVersion increment and could also increase the MinorVersion depending on the number of commits and on the complexity. MajorVersion will only be increased manually because it will mean a huge change in the codebase has been made.
Release action
Those release actions are present on my fork of the repo because I didn't want to disturb other contributors until I have something that is well thought, and it's working as expected.
The release action, at the moment, consists of three steps:
- pushing the tag with a specific format v
MajorVers.MinorVers.PatchVersionthat triggers the release action - building the project for each platform using cmake (Windows, Linux and Mac) and uploading the binaries using the action upload-artifact@v2
- getting version name from the tag
- downloading the artifacts (using the download-artifact@v2 action) and creating the release packages for users to be able to simply download the required binary. For example, the
AppCUI_linux_release.zipcontains an include folder where the headers are present, and the framework is built both statically and dynamically.
Results can be seen here.
Future development
I will extend the release workflow to support automatically increasing the version of the build when new code is merged into the release branch.
In conclusion, this was a wonderful experience and could learn a lot. I will continue to develop and adjust the workflow when I discover new and better methods.
Top comments (0)