Skip to content
Snippets Groups Projects

scriptelement.py: use stage_artifact() instead of stage_dependency_artifact()

Description

stage_dependency_artifacts() assumes the element in question is the element to be built and does some additonal things when it is workspaced.

This fixes failure when an element that is used in the layout of a "script" element is workspaced and one of the dependencies of the last successful build is no longer in the cache.


Edited by Abderrahim Kitouni

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • added 1 commit

    • dae098c5 - scriptelement.py: use stage_artifact() instead of stage_dependency_artifacts()

    Compare with previous version

  • Abderrahim Kitouni changed the description

    changed the description

  • Note that before very recently (this weekend), multiple calls to either Element.stage_artifact() or Element.stage_dependency_artifacts() have a bad side effect of failing to report overlap warnings.

    What's more, overlap whitelists cannot work across multiple calls.

    Another drawback of the original ScriptElement I noticed while porting it, is that the layout internally is stored as a list, and not a dictionary. That means ScriptElement stages multiple dependencies into the same staging location separately, instead of staging the common dependencies for the same sandbox location at once.

    This means that the staging order is not what one might expect, common dependencies written to the same target location later on in the layout will overwrite the same dependencies written before (which will also have side effects when intentionally overlapping files).

    The same goes for integration commands, if multiple elements are staged into / separately, the order of integration commands being run may conflict, and will almost certainly run redundant integration commands for common dependencies.

    It might be possible to at least address parts of this by:

    • Backporting OverlapCollector
    • Reporting warnings which were previously (erronously) ignored
    • Internally collecting the common dependencies targetting the same location and staging / running integration commands once for each target location (while preserving the current order dependent layout list for the target locations, which is bst-1 API)

    Since scriptelement is a core element, it could use some hidden facets of the Element.dependencies() and related APIs in order to stage/run integration commands on common dependencies of a list of elements (rather than being limited to iterating over one element's dependencies at a time).

Please register or sign in to reply
Loading