Determine Integration test mechanism

[c835722]

Project needs to develop a mechanism that can be run to validate the componentry is working.
This can then be used to ensure changes are not committed to the repository until the test passes.
This ensures the "feature" branch do not break the project before being merged to "develop"

[dougmcclure]

Would this be like using Jenkins or some other tooling?

[c835722]

At the moment the determination of the "health" of the project is done by humans. (ie. you).
That is, a users (le me) downloads the code runs the scripts, logs on and uses the UI to look at logs.
As time goes by there are a number of changes (many) that need to be made to the codebase. (enahnamcenets, bug fixes, etc)
These may be made by one to many developers/commiters.
Each time a user makes a change there need a non-subjective and automated mechanism to validate that the system still works as expected..

So what I am thinking is we need a automated test (integration test as there are many components) that validates a "codebase working" outcome.

That might be something like a CURL / REST based query against the SCAA UI that returns known set of valid data if successful.
(BTW, Could not find anything in the API FAQ yet ;-) https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/IBM%20Log%20Analytics%20Beta/page/API%20FAQs)

That way the workflow becomes something like.

git clone repo
branch feature
make change
run "codebase working" test.
if ok.
commit feature(s)
else
fix
merge features(s) to develop branch.
run "codebase working" test.
if ok.
commit feature(s)
else
fix
merge main
release.

So, some questions that follow for investigation.
Does the SCAA interface support an CLI for making a query?
What would the standard query be. Somehting for example ..
Validate that there WLP trace file entries in the current search dataset for the current WLP sample applications for a particular time and date. (Which validates that the WLP app is working, the log file adaptors is working, SCAA is working)

Further in a future enhancement where an automated build servers gets introduced (like say Jenkins) it could run the test.

The motivation for this enhancement is it allows the codebase to be scaled to support a multi-developer workflow which facilitates an increased rate of change.