CI checks on commit or push

[matuskalas]

Firstly, sorry for my lack of full understanding of the CI checks. Anyway:

1. Just checking: Is next_id checked?

2. Is it possible to either:

a) Automatically update date and time (and then also add the commit ID) inside the EDAM_dev.owl? Or would it then always have to generate a misleading fake commit? Are "artificial" commits allowed at all in Git?

Or

b) At least check that

• date is not older than yesterday &
• date+time is newer than the latest previous previous commit?

Or

c) First b) and if not ok, then proceed with a)?

[matuskalas]

Note: Both 1. & 2. were invalid (=bugs) in the previous commit (8364699b52b3a5d8d00b5b1f064f75b76f7fd1c0).

And as Travis says build passing, I'm changing 1. from question to bug.

[matuskalas]

(See also edamontology/edamontology#174) At every add/commit/push, also an automated reformatter would be desired. (NB. that a manually launched reformatter before every add/commit would just again keep being forgotten) Otherwise either the use of Protégé for editting must be forbidden, or DIFF, AND SUBSEQUENTLY ALL CHANGE TRACKING, MERGING, METRICS, etc., IS OUT OF ORDER!

[hmenager]

1 and 2 are indeed not currently checked by CI, but I think that they could (should?) ideally be both automatically adjusted, shouldn't they? Let's say that at every commit we:

• update next_id
• update the date to the date of the last commit
• reformat automatically.
  This would be awesome and facilitate a lot the process, right?

[matuskalas]

@hmenager: Sure! 👍
The date and time should then be the current, adjusted to GMT. Taken from some online service?
Would it then have to run within every add, or every commit?
And best if it could also hack some kind of a commit ID (SHA?) into the file (probably inside the version attribute).
And maybe even upload an unstable version to edamontology.org on every push.
Is it possible to bind automated update script to every add/commit?

One more note re reformatting: It's a total hell that the condemned protege randomises the order of especially relations, even every day! That seriously hampers change tracking.

[matuskalas]

3. Does Travis CI need to validate every commit, even if EDAM_dev.owl unchanged?

Would be less conflated if Travis CI was only listing commits that changed EDAM_dev.owl.

[matuskalas]

4. Check consistency of 'created in' and 'obsolete since'

• created_in stated exactly once for every concept
• obsolete_since stated for every deprecated concept (only, and exactly once, unless we add "re-precation" i.e. ressurection)
• continuity of created_in within the 4 subontologies (with respect to numerical parts of the ID. Well, the order of versions needs to be coded in a heuristics that will include "betaX" and "X.X")
• obsolete_since greater than created_in for each concept where present
• ...
• plus perhaps also check that all concepts are ordered alphabetically by their full IDs (that will make the subsequent checks listed above easier)

[hmenager]

I just corrected a bug in edamxpathvalidator, which tested for each concept
id>next_id and raised an error if true, whereas the good test should have been id>=next_id

[joncison]

@hmenager please move this to the right tracker (https://github.com/edamontology/edamxpathvalidator)

[joncison]

@hmenager cc @matuskalas : can you review what's done / to-do from above, create any new issues in https://github.com/edamontology/edamxpathvalidator as appropriate, then close this down?

[matuskalas]

I think we'll need to discuss the options and how to fit|update the whole workflow, @hmenager and me.