CI and testing

[Pazus]

Hi team!

Congratulations with the version 2 released! Great job. Looking forward to upgrade to it shortly.

The new versions starts the new era for the tool, doesn’t it? So he about configuring a CI pipeline to run all the commits and PRs, to validate against 11g, 12c, 12.2, to auto publish artifacts on releases?
As you know we use such approach for utPLSQL running tests in travisCI using docker containers. We have all the docker scripts published so anyone can create a small docker for an open source project.
I encourage you to give another try to the utPLSQL testing framework as it’ll allow you to treat tests results to mark CI build as failed, to measure coverage and report it to sonar.

Being one of the most known PL/SQL libraries out there I encourage you to join us in presenting the right way to build software for other oracle developers. Hope now you have some free time to spend on the environment.
Let me know if you need any help.

[jsumners]

Hey @Pazus, I am definitely interested. Would you mind submitting a PR? If so, please leave out the SonarQube stuff and focus only on the unit testing.

[dsnz]

hi :)

just a comment

we do use utPLSQL before any release (yes, at least me ! and I also use it in development when needed), it's just not automated

• for me it's not worth the complexity and effort to do this automatically at this moment, we do not release so often and I verify any PR from contributors first before I merge it
• utPLSQL testsuite has one fewer test because a contributing user did not supply a test in the utPLSQL framework (it's too much to insist on this right now for contributors but from my part all contributions are checked); I will add this test once I can modify it and enhance it to be more thorough (test passed in certain platforms when there was a bug ! - it's more important that a test is effective and is catching problems -)

as @jsumners says any addition is of course welcome, if it's setup in a way that is optional to our users who download updates or clone the project and does not burden their installation and easy use of the project

[jsumners]

@dsnz the idea is that when someone contributes a new feature, or a fix, then we are able to see that it doesn't break existing functionality simply by reviewing the automated check. This is a good thing. While it would be possible for contributors to run the tests on their local systems, that isn't the point (to require them to do so). The point is that once they submit their pull request an automatic test is run to provide them, and us, the necessary feedback.

Going forward, we should be able to issue a release after pretty much every successful merge of a pull request; see the outline of versioning under the v2.0.0 heading in the changelog. Automated testing makes this feasible.

[dsnz]

I totally subscribe to this idea 👍