Skip to content

Understanding run.sh and taptests.sh

Aryan Gupta edited this page Jun 11, 2023 · 4 revisions

In this directory there are two files:

Run.sh

Copying the file to the root

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

For specific function

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

Disabling tap_test and actions_test

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.

Building Documentation

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

Updating Release Notes

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.

Updating the signature

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

Taptest.sh

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

Clone this wiki locally