1 Overview
- sync script
- wird nächtlich und bei releases ausgeführt: /home/scripts/crontab_sync_cvs.sh (wrapper script) /home/scripts/sync_cvs.sh checked repositories aus und führt das php script aus
- /var/www/ChangelogManager/cvs_changelog_dbsync2.php
- updated die datenbank mit den changes und generiert tagdates.inc.php (wird fuer merges/branches im web ui gebraucht)
- web UI
- /var/www/ChangelogManager/changelog.php
- kümmert sich ums anzeigen, raussuchen der changes sowie das hochladen des public changelogs auf gentics.com
- datenbank (changelog)
- portal.office: changelog / auf gentics.com: changelog
- publishen – wird vom web UI gemacht und dann per script /var/www/ChangelogManager/copychangelogtoinfoportal.sh hochkopiert.
- change → changelog workflow
- user committed change im CVS
- changes werden per sync script am portal.office vom CVS per cvs2cl ausgelesen und in die datenbank geschrieben
- per branch tags wird per versions.inc nachgesehen zu welchen branchcollections der change gehoert und mit in die DB geschrieben
- web interface:
- user waehlt start und end-tags aus (per versions.inc und builds.inc)
- script sucht alle changes zwischen start und end tags
- alle merges (merges.inc.php) die in dem zeitraum sind (start tag/end tag wird zu datum resolved ueber tagdates.inc.php)
- merges werden an sql statement dazu gehangen
- anzeige aller resultierenden changes (filter nach managed/unmanaged, public, etc.)
- versions.inc: wird per hand gewartet auf dev6.office – hier sind alle branchcollections und dazu gehoerigen repositories und
- branches eingetragen
- builds.inc: wird automatisch per ‘build’,‘dist’ und ‘release’ scripts geschrieben (ebenfalls am dev6) – beinhaltet das datum wann jeder release gebuildet wurde, testing wurde bzw. released wurde tagdates.inc.php: wird automatisch per changelog sync script geschrieben (am version.office) – beinhaltet das datum aller im CVS vorhandenen tags .. wird zum resolven von tag nach datum verwendet (da in der datenbank die changes nur per datum drin stehen)