Skip to content

limits.md

Latest commit

 

History

History
61 lines (47 loc) · 2.88 KB

limits.md

File metadata and controls

61 lines (47 loc) · 2.88 KB
Raw

Limits

Where the inputs of these actions stop: what you can ask them for, and what you cannot. Everything here is a boundary you can hit while using them, rather than a caveat about their internals.

Note

Every limit on this page is a limit for now rather than a design. The inputs that shape a build are provisional, and the work to replace them is intended to remove most of what follows. Until it lands, this is what the inputs reach.

The inputs are not create_distribution's option set

The build calls PackageCompiler's create_distribution, and every option it passes is either fixed by the action or derived from an input. There is no passthrough, so an option no input exposes cannot be set at all. Three worth knowing about, because you may want them:

  • Lazy artifacts are not bundled, so a dependency declaring one relies on it being fetched at run time.
  • Transitive dependencies are not forced into the system image, so a package that does not load all of its own dependencies when it is loaded leaves those to be compiled on an end user's machine rather than baked in.
  • The release banner cannot be set as an option. sysimage-script reaches the same thing, which is what the customization example does.

The copy globs arrive as plain strings

additional-copy-globs is newline-separated text, and each line becomes a pattern as written. PackageCompiler accepts more than patterns — the case-insensitive filename matching the action uses for license files among it — and none of that can be expressed through a workflow string. If you need case-insensitive or otherwise non-literal matching, there is no way to ask for it.

The system image script composes rather than replaces

sysimage-script cannot displace the action's own script, which rewrites the package origin paths baked into the image. Yours runs after it. That much is deliberate — it is what keeps pathof and pkgdir resolving inside the distribution on an end user's machine — but it does mean the rewriting cannot be turned off or substituted.

PackageCompiler is provisioned at a pinned revision

The build installs PackageCompiler itself, into a shared environment of its own, at a revision the action pins. That revision is not configurable and there is no way to opt out of the provisioning: working from a fork of the compiler, needing a different revision, or wanting it pinned at manifest level rather than by the action, you have no way in. Nothing in the distribution's own project or manifest affects which compiler builds it.

The pin is there so that two runs build with the same compiler.

Nothing is versioned

Pin a commit SHA, as the README asks. A workflow that has to keep working cannot track a branch here, and the inputs above are not the only ones that may still change.