* Add dameng stand
* Rename compose file
* Move damengdb files in tests folder
* Remove copy bin disql command
* Refactoring damengdb stand
* Update readme instructions
* Refactor: update readme
* Refactor: add note
* Update run command for disql copy
* Remove scripts and add volumes in compose file
Stand was updated. Main changes that scripts for prepare environment was removed.Now damengdb image can be pulled from hub.docker, also disql will be mounted from damengdb container in documentserver container.
* Update damengdb image version
* Actualized damengdb compose file
Use damengdb image from onlyoffice repo. Also do not use develop documentserver build anymore
* Don't mount entrypoint script anymore
After release it will be inside the image with the necessary edits
* Add the ability to build an image before compose is started
* Dameng: Execute schema on build stage
Now if you want use damengdb, you nedd build own image, schema for Documentserver will be create on build stage. Add dockerfile for the build dameng image. Also disql bin file don't share between containers
* Actualize readme for damengdb stand
* Editing typos
* Remove useless lines
* Small cosmetic change
* Remove useless volume from compose file
* Use default password for check connection
* Remove `image` filed from compose
* Add zap scanning for DocumentServer
* Set branch name as ref for manual trigger
* Use master as default zap action branch
* Move zap action to master branch
* Fix token variable name
* Small cosmetic fix
* Modify zap action trigger condition
Run zap scanner only when documentserver edition hit community and branch hit in `release/` or `hotfix/`
* Add the ability to rebuild images
Rebuilding images will be done manually (for now). The choice of the number of rebuilt releases is available (1 by default), the choice of repositories for pushing rebuilt images is available (4testing by default).
Principle of operation:
Through the api of the docker hub, we get the last launched tag that falls under the pattern x.x.x.1, after that the tag with the assembly of which the minor tag x.x will be sent will be calculated. Next, at one of the build steps, the number of the previous release will be received, for example x. x.x.4 which will mean that the current one will be x.x.x.5
* Add login to dockerhub
* Refactoring code
Set some variables for all rebuild-info job. Also set default values for repository and quantity variables
* Refactor: remove push trigger
* Refactoring code
* Refactor: Unlinking a version
* Submitting the latest tag for the latest release only
* Refactoring stable images release versioning
The new principle of stable docker images versioning: release numbering is now not by build number, but by serial number.
* Refactoring: fix non-example image pull tag
