Difference between revisions of "Integrity Checks"

Latest revision as of 14:36, 15 June 2009

Integrity checks are part of the Repository Server's ability to ensure cohesiveness of an uploaded package. All integrity checks are performed using the server's holding area.

Integrity Checks Stage 1

There are a number of integrity checks to be performed on any package. All checks are static, in that configuration data is checked or compilations are made. Integrity checks do no perform any unit tests on the package library code because these run-time (dynamic), regression checks should be performed by the package's maintainer before the package is uploaded. It is uncertain just how many and how long such unit tests may take run which could significantly delay the migration of a library from the holding area to the repository.

The very first checks to make are to ensure the uploaded package's package is compatible with all dependent packages. Packages may support one, some or all platforms so it is imperative this information is checked first because compilation will not succeed if there are supported/unsupported platform differences. For instance, the WEL is a Windows specific library. A library author could be finishing up development of a platform independent library on Windows, which has already been developed for various *nix platforms. To support Windows a reference to the WEL was added in the library ECF, but added unconditionally. The library compiles on Windows just fine and did compile on all *nix platforms. The author then uploads the packaged library. The library will no longer compile on any other platforms except Windows because of the unconditioned reference to the WEL. The same configuration checks will be needed to ensure Void-Safe and non-Void-Safe package, unless the repository supports only Void-Safe packages. Finally all referenced packages need to be checked to ensure those package exist in the repository.

After the package fundamentals have been checked the uploaded package will built, if there is an associated build script. If the build script succeeds in building the package's platform specifics then an Eiffel compilation will be performed, compiling all classes in the library. All classes are compiled to ensure all classes are usable, by anyone choosing to consume the package library in their project, and there are no junk classes in a package. Only an Eiffel compilation is performed and used for integrity checks, rather than on including a C compilation, because it will be impossible to guarantee all external, optional dependencies exist on the repository server (or the server performing the checks.)

All compilations can be performed on the same server, given enough resources, or in a cloud managed by Eiffel Software. Servers will either utilize virtualization and guest OSs and specific platform architectures, or delegate the integrity checks to a dedicated machine running the applicable OS/platform architecture.

Up to this point any failure in checking configuration compatibility or the Eiffel compilation, will be reported to the package maintainer with a description of the cause or a compilation report. A failure at this point is cause for the library to be rejected and removed from the holding area. The package will not be integrated into the stable repository.

Integrity Checks Stage 2

Even a package passing the first stage of integrity checks is still not integrated into the stable repository, but becomes a candidate for integration. The final check is to compile all packages depending on the uploaded package for integrity, to strengthen library code compatibility. Any dependent package with a set maximum version number lower than newly uploaded package will not be checked or compiled, only those equal to or greater than because the newly uploaded package will be used by the latter. All dependent packages are compiled before taking any action to ensure a more concise report to the package maintainer, in the event of an error.

Once all of the dependent packages have been compiled against the new package, still in the stable repository, the server will check each package's library compilation record for failures. On one or more failures the uploaded package's maintainer will be emailed with a call to respond regarding what action to take. The new package may have introduced breaking changes and as such is considered to be a correct package fit for integration to the stable repository. On the the other hand the library author may have made a mistake, breaking other code in the repository and wants to fix this. The maintain will respond to the email by selecting either a "Expected breaking changes, notify all dependent package maintainers (breaking change)" or "I'll fix it (recommended)" links, with a list of packages unable to compile. The former indicates to the repository the broken compilation was to be expected due to a breaking change. The cause of this will set all dependent packages with a maximum version number to the previous version of the uploaded package, as it is known to compile. All maintainers of the dependent packages, no longer able to compile with the current version, are emailed with with compilation error information and a message indicating the actions taken. The uploaded package is then integrated into the stable repository and now multiple versions of the package exist there (old one of compatibility and the new one.) However, in the case the uploaded package maintainer opts to fix the package, the package is rejected and is removed from the holding area. It is expected a new version of the package be uploaded and all checks performed again.