Wed, Jan 13
Nov 3 2020
- 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.
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").
Oct 26 2020
I think I've got a small tidbit to add on a specific use-case with Jenkins. I had been using pipeline builds which are working nicely but I just tried to setup a multi-branch pipeline build and this requires the branch name in the Jenkins URL of the HTTP request triggering the build. I suspect in this case the proper thing to do would be to trigger and build twice. I guess that's more of an on-branch-change sort of situation than on-commit and using those triggers in Herald (they look to be present, I haven't used them) and having that information passed on to Harbormaster as mentioned could fill the need.
Jul 16 2020
Please use Discourse to discuss Phabricator. (And please don't bump unrelated tasks from five and a half years ago.)
Is this really a harbormaster problem though? I would have located it within Differential.
Jun 4 2020
May 20 2020
Apr 30 2020
See https://discourse.phabricator-community.org/t/typeerror-w-arc-diff-when-build-plan-view-policy-does-not-contain-user/3820/. The reproduction case is "policy makes the build plan invisible".
Apr 28 2020
I'm having trouble reproducing figuring out how to reproduce this locally.
Feb 24 2020
See also PHI1605 (internal), which provides some evidence that:
Feb 13 2020
Feb 7 2020
A saved state is likely something like this:
I'd like to leave behind a "Results were GC'd on X/Y/Z" message when we GC these so it's clear what's going on.
Feb 5 2020
Feb 4 2020
See also PHI1628, which reports that a 4MB blob of test details is slow to render.
Jan 30 2020
We have no open customer requests for this and it's very complex, so I don't currently plan to implement it.
Another use case :
Oct 29 2019
Sep 27 2019
One broad problem here is "chain of custody" issues in T182. A "Saved State" can easily accommodate multiple representations, and the plan above imagines using Drydock to build tags/branches out of non-repository representations, so we'd have cases where a given "Saved State" has a way to build it with a "patch list" (from the client) or a "ref pointer" (from Drydock).
Sep 25 2019
The problem isn't that it's in rough shape (I'm fine with bringing rough stuff upstream), but that it's something I may eventually want to license as a paid extension. I generally want to stop bringing "free glue for paid systems" upstream (T13229).
How about landing this as a prototype?
Sep 23 2019
(This has been made to exist, at least roughly; see PHI1448.)
TravisCI sold to Idera and is no longer "cool".
I generally don't plan to upstream any more support for third-party build tools, since I don't think a future where Phabricator is free glue for a bunch of paid systems is desirable. The pathways forward here are either:
Aug 29 2019
Also an example how "per-push notification" is implemented in Github events/webhooks:
I actually found my way here from discourse where the need for this was discussed:
Aug 20 2019
Aug 8 2019
Jul 24 2019
Jul 23 2019
Jul 12 2019
May 17 2019
This stuff is largely resolved, but survived by a few remaining issues in T13290.