See PHI1919. An install would like API access to build steps.
Description
Description
Revisions and Commits
Revisions and Commits
Related Objects
Related Objects
- Mentioned In
- 2021 Week 4 (Late January)
- Mentioned Here
- T13449: When objects are created with a particular subtype, apply subtype-appropriate validation rules
D15352: Remove obsolete, confusing Harbormaster builds steps
T13248: Support enabling and disabling (and making other adjustments to) custom fields based on object subtypes
Event Timeline
Comment Actions
HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").
By default, BuildStepQuery does not build or attach Implementation objects; instead, they are built and attached on-demand. This isn't a problem in and of itself.
Here, ApplicationSearchEngine does not include PhabricatorCustomFieldSearchEngineExtension in the list of BuildStep extensions because BuildStep does not expose any searchable fields. This is incorrect: it should be permissible for an object to have searchable fields only (although this would be a bit unusual), or result fields only, or both.
This partly occurs because a "generic" BuildStep (with no specific implementation) has no custom fields.
This is entangled with T13248 and only directly impacts the ability to return results from harbormaster.buildstep.search, which I can plausibly cheat my way through instead, perhaps.
Comment Actions
Limitations:
- There is no way to pull custom field values with *.search. See above.
- There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
- There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
- As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
- There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.