Closed claustres closed 1 year ago
A solution to be able to use a similar process between modules and apps is to avoid versioning dev/test Docker app images and only number prod images. Indeed, there is no need, in this case, to increment the version number on the master/test branch after a release as the previously generated artifacts (dev/test) will be erased anyway.
The problem with this approach is that we cannot have multiple versions of Kano running in different production environments simultaneously. Indeed, as a new Kano release will erase the image of the previous one, any custom build relying on the previous image will not be able to run anymore. This process could be acceptable on customer-specific applications based on Kano but not on Kano itself. We should at least manage a dev/test branch and accept that when a version enters the test flavor no patch is possible on the running production version as the code in the test branch has been upgraded.
About changelog we now use GitHub/GitLab issues to track changes in order to simplify the release process.
Since we we use Github/Gilabl track changes, we can close this issue
The current release process is different for modules and applications, we should analyze if it's possible to make them more similar in order to avoid confusion. Moreover, there are two different changelog generators currently used.
github-changelog-generator used in Weacast, Krawler, KDK and derived applications creates a log file based on tags, issues and merged pull requests from :octocat: GitHub (so it cannot work with eg GitLab). It requires to install (e.g. for Windows) Ruby and its DevKit. Last but not least, it suffers from the following issue so you might have to edit the generated changelog when pushing on different branches or systematically merge changes to
master
before generating the changelog so that all issues are closed in Github.generate-changelog used in Kaabah, Kargo and Krawler jobs creates a log file based on git commits (so it can work with eg GitLab). It does not require any third-party dependency. However it suffers from an issue so that if the commit message includes a URL it will break. Morevover, we did not test it with branches. Last but not least, it does not allow to integrate into the changelog issues that have been closed without any related commit (eg a bug appearing in an app and coming from the KDK dependency).
The following automated process applies when releasing a patch, minor or major version of a module using the first changelog (eg KDK):
A different process applies for the apps as:
Imagine we are currently working on the next version of the app (
1.2.0
in package.json =>1.2.0-dev
image in Docker Hub) on themaster
branch:test
branch from themaster
branch (test-1.2
=>1.2.0-test
image in Docker Hub)1.3.0
=>1.3.0-dev
image in Docker Hub)test
branch (prod-v1.2.0
=>1.2.0-prod
image in Docker Hub) in the git repository and push ittest
branch (1.2.1
in package.json =>1.2.1-test
image in Docker Hub) so that the previously generated artifacts will not be erased by new commits entering pre-productionThe following automated process applies when releasing a patch, minor or major version of a module using the second changelog (eg Kargo):
The process used for the modules does not allow to manage multiple branches. Indeed, each commit on the master branch erases the
latest
tag on the Docker Hub while any tag generates a release (eg1.2.0
tag).We have tried to use a similar process for customer-specific applications based on Kano, eg GIFT. However, it is not really finished and causes some problems. First by erasing the previous image while committing on the next release, ie the version number remains eg
1.2.0
until the1.3.0
release has been published so that the1.2.0-dev
image in Docker Hub actually contains the next1.3.0
release code. Second because we assume that similar versions exist in dev/test flavor while patch versions only exist in test flavor.