-
-
Notifications
You must be signed in to change notification settings - Fork 367
Understanding run.sh and taptests.sh
In this directory there are two files:
Copy the files to the root of your repository on run.sh (lines 39 to 43)
QUERIES_DIRS=$(ls docqueries -1)
TAP_DIRS=$(ls pgtap -1)
QUERIES_DIRS="dijkstra"
TAP_DIRS=""
Those 2 variables QUERIES_DIRS
and TAP_DIRS
hold the directory names that will be tested
Lines 1 & 2 from above is choosing all directories to be tested, but that is not normally needed. Lines 4 & 5 from above are overriding the above with docqueries tests to be done on dijkstra and no tap done at all
If I am working on bdAstar
I change to:
`QUERIES_DIRS="bdAstar"
TAP_DIRS="bdAstar"`
Now, that run.sh is local to your computer, you can modify as you need ... The last part of that file says something like:
function test_compile {
<code>
for d in ${TAP_DIRS}
do
bash taptest.sh "${d}" "-p ${PGPORT}"
done
for d in ${QUERIES_DIRS}
do
#tools/testers/doc_queries_generator.pl -alg "${d}" -documentation -pgport "${PGPORT}"
tools/testers/doc_queries_generator.pl -alg "${d}" -pgport "${PGPORT}"
done
tap_test
action_tests
}
test_compile
The very last lines of the function:
tap_test
action_tests
Is not something you want to do all the time tap_test will test everything in one go, and yes it takes a long timeaction tests will test things that are tested on the CI, so you can let the CI test that Therefore have something like:
exit 0
tap_test
action_tests
}
that will exit the function and not do the rest of the function code.
I normally move around the build_doc
above and below the exit 0
, if I touch the documentation I move it up, if I am not changing documentation I move it down.On build_doc
function depending on what level of rebuild of the documentation I want, I uncomment lines 103 or 105, or I just do that removal rm -rf build/doc manually
From the lines on action_tests
function (lines 76 of run.sh) I run manually on the terminal
tools/release-scripts/notes2news.pl
when oc/src/release_notes.rst
gets modified.
tools/release-scripts/get_signatures.sh -p ${PGPORT}
from action_tests function above code will update this file: pgrouting--3.6.sig
Note that: whatever you do, you can not remove a function signature This is tested here: https://github.com/pgRouting/pgrouting/blob/develop/.github/workflows/check-files.yml#L19 test_signatures.sh
Within a minor ... say 3.0.0 3.0.1 ... 3.0.infinity the signatures can not change, that is why there is only one file per minor Within a major 3.0.x 3.1.x ... 3.6.0 3.1 inludes all the lines in 3.0, but can have more functions
diff pgrouting--3.0.sig pgrouting--3.1.sig
84a85
> pgr_dijkstracost(text,text,boolean)
92a94,95
> pgr_dijkstra(text,text,boolean)
> _pgr_dijkstra(text,text,boolean,boolean,boolean)
The difference between 3.1 and 3.0 are 3 more functions This PR change where its adding more OUT parameters, do not change the signature (aka the IN parameters remain the same) So for that file purposes there was no change. so this commands results is empty
diff pgrouting--3.5.sig pgrouting--3.6.sig
there has not been a new function PS on that no new function, so that tests will pass, but the update needs a fix which we will worry later conclusion of file run.sh Has the commands that are needed one time or another when developing pgRouting Copy to your root repo and modify to accommodate your needs like Operation system, location of libraries, version pf postgres of compiler, what you want to test etc Do not add the customized run.sh file to the repo
That is executed on the cycle that is in the runshell
for d in ${TAP_DIRS}
do
bash taptest.sh "${d}" "-p ${PGPORT}"
done
Remember you also copy that file to the root of your repo, and also customization is needed Line 37 is overriding line 36, normally its quiet, (aka one line saying how many tests passed/failed) but sometimes I have to pinpoiont which test if failing so I comment out line 36 and becomes verbose line 40 for GSoC purposes at this time of the program make it:
PGRVERSION="3.6.0"
Later on when testing the update, we will also test on 3.2.0 (aka an old version)
For individual tests you can certainly remove any line here: https://github.com/pgRouting/pgrouting/blob/main/tools/developer/taptest.sh#L59
in your customized copy of course
But not what is needed for the tests -f sampledata_pgtap.sql <---
no sample data nothing will work.
The data for this ones is big, needed for the vrp functions,which you are not testing so, yes remove in your customized version
-f vrppdtw_data.sql
-f solomon_100_[rc101.data](http://rc101.data/).sql
I recommend that:
- make the run.sh work without testing pgtap
- then run a test (on your function that you are modifying)
- remove a line on taptest.sh
- execute tests again
- if the test fail, put the line back, and remove another
- if test pass remove another line
So as you can see that is done locally on your computer, because you are not testing anything else. the CI actions will take care of testing everything else The CI actions use this file setup_db so please do not modify that file if you modify and delete a line there, the something will fail on the actions