Integrity Checks

Integrity checks are part of the Repository Server's ability to ensure cohesiveness of an uploaded Eiffel Library Repository package.

Integrity Checks Pt. 1

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

The very first checks to make are to ensure the uploaded library's configuration is compatible with all dependent libraries. Libraries may support one, some or all platforms so it is imperitive 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 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 libraries, unless the repository supports only Void-Safe libraries. Finally all referenced libraries need to be checked to ensure they exist in the repository. It is possible to reference a library is removed at some point and those libraries need to update.

After the library fundamentals have been checked the uploaded library will built, if there is an associated build script. If the build script succeeds in building the library'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 library in their project, and there are no junk classes in a library. Only an Eiffel compilation is performed and used for integrity checks, rather than on including a C compilation, because it will be impossible to guarentee 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 library 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 library will not be integrated into the stable repository.

Integrity Checks Pt. 2

Even a library 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 libraries depending on the uploaded library for integrity, to strengthen code compatibility. Any dependent library with a set maximum version number lower than newly uploaded library will not be checked or compiled, only those eqaul to or greater than because the newly uploaded library will be used by the latter. All dependent libraries are compiled before taking any action to ensure a more consice report to the library maintainer, in the event of an error.

Once all of the dependent libraries have been compiled against the new library, still in the holding area, the server will check each library's compilation record for failures. On one or more failures the uploaded library's maintainer will be emailed with a call to respond regarding what action to take. The new library may have introduced breaking changes and as such is considered to be a correct library 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 library authors (breaking change)" or "I'll fix it (recommended)" links, with a list of libraries 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 libraries with a maximum version number to the previous version of the uploaded library, as it is known to compile. All maintainers of the dependent libraries, 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 library is then integrated into the stable repository and now multiple versions of it exist there. However, in the case the uploaded library maintainer opts to fix the library the library is rejected and is removed from the holding area. It is expected a new version of the library be uploaded and all checks performed again.