API change cycle

How to handle if the API check tools raises a problem?

API change acceptance flow

1. An immediate defect is logged and it is assigned to the developer that caused it. If needed, the defect is split into multiple issues.

2. The developer reviews it:

2.a If he made the API change by error, he reverts the change by a commit to PI. The commit should be used to resolve the immediate issue logged to the change. -> Done

OR

2.b The developer adds a comment explaining:

• Why the change is needed
• What has changed
• What a developer needs to do if he is affected by the issue
• The immediate issue should be linked with the issue for the original change
• Reassign the issue to DME, but leave it in new state

3. DME approves and rejects the exception by simply adding a note to the defect, assigning back to the developer and setting it to status scheduled (since it is now triaged).

4.a If rejected, the developer rolls back the change and implements it in a different way that does not cause an API change. The developer sets the status to resolved when he/she is done.

OR

4.b If approved,

• The developer adds a note to the wiki page describing all API changes: http://wiki.openbravo.com/wiki/API_changes
• The new change is added to the PI group of changes, for each new change the minor number is incremented
• The new wiki entry should have a link to the immediate issue in mantis

This short info is only possible if the wiki description and/or immediate issue does contain all details which could be interesting to a developer affected by that change.

Fix API check tool

Once the API change is accepted, the developer has to make sure the the api change is not longer raised by the check tools:

For all changes the developer needs a mercurial clone of the api-checks repository: https://gitlab.com/openbravo/ci/backoffice-api

Then, the right files corresponding to the accepted api change needs to be updated/committed/pushed. This commit should be used to resolve the immediate issue used to track the api problem.

• for model changes (when the model check test did notice the change):
  • reference directory: <api-checks>/model. This contains a partial copy of src-db/database/{sourcedata,model}
  • To acknowledge a change the xml files corresponding to the change needs to updated.copy the needed files including your changes into this folder and commit/push
• for java changes (when the java api test did notice the change):
  • reference directory: <api-checks>/java/reference/
  • The reference files for the java test are binary files.
  • To acknowledge a change a file needs to be downloaded from: http://builds.openbravo.com/japi/
  • The file needs to replace the file <api-checks>/java/reference/java.japi.gz
  • Then commit/push to api-checks
  • How to pick the right file to download? The files to download correspond to the CI build for the module-integrity-test with the same build number. Example: you want to acknowledge all changes raised in build 41 on: http://builds.openbravo.com/view/ERP-tests/job/erp_devel_pi-module-integrity-test/41/ Then download the file 41.japi.gz as a new reference file (as it included all this changes)