You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upstream PhpReport is provided with yearly releases, but that doesn't fit known actual deployments which are updated from the repository more often. It would be ideal to align upstream with this delivery process. We would also reduce the effort done in releases, which are completely manual at this point, and minimize errors.
We would have to guarantee that an admin is able to replace the files in their deployment with the files from the main branch in any given point (individual commits in branches merged into main would not count), and then be able to easily match their config and database. So I think we should:
version the database (already done, maybe change from "2.x" version names to incremental integers like db_version 3, 4, etc.)
for every change in the DB we commit in the future, we would bump the DB and probably include an upgrade script too
version the config file (e.g. define(CONFIG_VERSION, 2))
remove config.php from the repository to prevent overwriting local config (in fact, we already exclude this file from the release tarballs)
add initial checks in the program (during login?) to find out if it's running the correct DB and config version
The text was updated successfully, but these errors were encountered:
@jaragunde cool, agree we should start prioritizing this.
A bit related, could you give me admin powers in the repository? I want to setup a github action to run the automated tests on pull requests and in the default branch
Upstream PhpReport is provided with yearly releases, but that doesn't fit known actual deployments which are updated from the repository more often. It would be ideal to align upstream with this delivery process. We would also reduce the effort done in releases, which are completely manual at this point, and minimize errors.
We would have to guarantee that an admin is able to replace the files in their deployment with the files from the main branch in any given point (individual commits in branches merged into main would not count), and then be able to easily match their config and database. So I think we should:
define(CONFIG_VERSION, 2)
)config.php
from the repository to prevent overwriting local config (in fact, we already exclude this file from the release tarballs)The text was updated successfully, but these errors were encountered: