Skip to content

EIF 0.2.4

Latest

Choose a tag to compare

@mike-arbuzov365 mike-arbuzov365 released this 29 Jul 16:28
dbad200

Four defects, all of them things the tooling told the operator that were not
true. Three were found by running it on real repositories rather than by
reading it, and the oldest had been failing since 0.2.0 in a suite that no
workflow runs on its own.

Fixed

doctor called an integration misconfigured when its executable never
started.
Only exit code 127 counted as "could not be started". A Windows
shim that cannot reach its interpreter exits 9009 through cmd.exe, and a
failed spawn exits 1, both with nothing on stdout. Both were reported as
misconfigured, which sends you to a configuration file to fix a value that
is already correct. They now report unavailable, whose remediation already
says the right thing. A probe that exits 0 and prints an unparseable or
out-of-range version did start, and is still misconfigured.

upgrade refused to run because of drift that the upgrade repairs. The
pre-flight verification of the pinned runtime failed on a drifted
knowledge/index.md, and told you to run eif_init.py again, which is
exactly what the blocked command wraps. Because eifctl projects upgrade
pre-flights every project, one project's index drift stopped the whole fleet.
eif_verify_runtime.py --pre-upgrade now reports the two checks that the
managed-state refresh regenerates as notes rather than failures; the
post-upgrade run still checks everything, and bundle integrity still fails
closed in both.

upgrade told people to revert changes that did not exist. On a fresh
clone of a connected project the framework axis succeeded, the tree stayed
clean, and the command exited 1 saying "do not commit the changes." The only
finding was the absent .eif/workspace-runtime/, which is gitignored by
design and which every first checkout on a new machine lacks. That case now
succeeds and says what to run. A genuinely failing check distinguishes a
clean tree with nothing to revert from a run that did write managed state.

The framework's own repository had the line-ending defect it fixes for
instances.
Seven top-level Markdown files reported as modified forever
under core.autocrlf=true, with identical blobs and an empty git diff.
.gitattributes now pins the repository to LF. No blob changed.

How three of these stayed hidden

scripts/tests/test_package_build.py had three failing checks on 0.2.0
through 0.2.3. It runs only through run_all.py and through
release-check.yml, which is workflow_dispatch only and has never been
run. The cause was in the suite itself: its Windows test shim is a .cmd
file, cmd.exe parses batch files in the console OEM code page rather than
UTF-8, and the suite deliberately runs from a directory containing a
non-ASCII character, so the shim could not reach its own interpreter. The
shim now carries paths through the environment. The product defect above is
separate and real: it is what made a dead shim look like a configuration
error.

Known limitations

Unchanged from 0.2.3. The package is distributed through GitHub Releases
rather than PyPI. integrations/vendor-docs/manifest.json still does not
validate against the provider-manifest schema; nothing enables that
integration, so no doctor run reaches it. release-check.yml still runs only
on demand, which remains the most likely place for the next silent
regression.

Install

python -m pip install ./engineering_intelligence_framework-0.2.4-py3-none-any.whl
eifctl version