Flyway repeatable migrations - Checksum doesn't change but Flyway still executes scripts - oracle

Question

I'm using Flyway 4.2.0 Community Edition. It's possible that this issue is resolved in a future release, but our DB upgrade project is still a ways out and no luck with being approved for licensing to go to Enterprise.
We've been successfully using Flyway for migrations on our Oracle databases for about a year (11.2.0.4 and 11.2.0.2) using standard migrations and with the default prefix (V) and suffix (.sql). We had a homegrown approach to handling our source, but we'd like to move to Repeatable Migrations to simplify things.
We have previously exported all of our PL/SQL into a git repository, using specific suffixes for different object types (trigger=.trg, procedure=.prc, etc.). We'd like to keep these suffixes, but the version we're on doesn't support the newer parameter flyway.sqlMigrationSuffixes, so in we're trying to use a solution with a list of suffixes and a for-loop. This solution is mostly working in my testing, with two very notable exceptions: package specs and package bodies (stored separately as .pks and .pkb).
Here's the script we're using to do our migrations (I know it needs work):
###Determine deployment environment for credential extraction
echo "Determining the deployment environment"
case "${bamboo_deploy_environment}" in
prod)
path=prod
dbs=( db1 db2 db3 )
;;
stage)
path=stage
dbs=( db1 db2 db3 )
;;
*)
path=dev
dbs=( db1 db2 db3 )
;;
esac
echo "Environment for credentials unlock is ${path}"
packages=( .sql .trg .pks .pkb .fnc .typ .java .class .properties .config .txt .dat )
echo "Packages to loop through when deploying flyway are ${packages[*]}"
echo "Databases to run against in this environment are ${dbs[*]}"
###Flyway execution stuff
for db in "${dbs[#]}"
do
if [ -z ${db} ]; then
echo "No db specified"
exit 2
else
echo "Working on db ${db}"
case "${db}" in
db1)
sid=db1
host=db1.fqdn
port=$portnm
;;
db2)
sid=db2
host=db2.fqdn
port=$portnm
;;
db3)
sid=db3
host=db3.fqdn
port=$portnm
;;
esac
fi
echo "Current directory is `pwd`" && echo "\n Contents of current directory as `ls -l`"
echo "Executing Flyway against ${db} for package ${pkg}"
for pkg in "${packages[#]}"
###Target the specific migrations starting folder (it goes recursively)
do
case "${pkg}" in
.sql)
loc=filesystem:${db}/migrations
;;
*)
loc=filesystem:${db}
migrateParams="-repeatableSqlMigrationPrefix=RM -table=REPEATABLE_MIGRATIONS_HISTORY"
;;
esac
echo "Running flyway for package type ${pkg} against ${db} db with location set to ${loc}"
baseParams="-configFile=${db}/migrations/base.conf -locations=${loc} -url=jdbc:oracle:thin:#${host}:${port}:${sid}"
migrateParams="${migrateParams} -sqlMigrationSuffix=${pkg} ${baseParams}"
addParams=" -ignoreMissingMigrations=True"
flyway "repair" "${migrateParams}"
flyway "migrate" "${migrateParams}${addParams}"
echo "Finished with ${pkg} against ${db} db"
unset baseParams
unset migrateParams
unset addParams
done
done
echo "Finished with the migration runs"
My approach has been to run the deployment in an environment, export the data from the REPEATABLE_MIGRATIONS_HISTORY table (custom table for the repeatable migrations) as insert statements, then truncate the table, execute the inserts, and run the deployment again using the same deployment artifact. On every file type Flyway is correctly evaluating that the checksum has not changed and skipping the files. For the package spec (.pks) and package body (.pkb) files, however, Flyway is executing the repeatable migration every time. I've run queries to verify, and I'm getting incremented executions on all .pks and .pkb files but staying at one execution for every other suffix.
select "description", "script", "checksum", count(1)
from FLYWAY.repeatable_migrations_history
group by "description", "script", "checksum"
order by count(1) desc, "script";
Does anyone else out there have any ideas? I know that these source files should be idempotent, and largely they are, but some of this PL/SQL has been around for 20 plus years. We've seen a couple of objects that throw an error on the first execution post-compile before working perfectly thereafter, and we've never been able to track down a cause or solution. We will need to prevent unnecessary in order to promote this to production.