<@U01PZK60W2F>: i’m going to be adding additional ...
# development
w
@curved-television-6568: i’m going to be adding additional metadata to
BuiltPackage
, and was wondering if you had any thoughts on whether streaming logging would be beneficial as packages are built: https://github.com/pantsbuild/pants/issues/13153
c
I have ben thinking about if it would be feasible/interesting to present the output produced when running docker build. Other than that, I would be more interested if there was a way to hook up a rule that takes BuiltPackage as input for any custom post processing (or rather after publish..) ;) or some other mechanism for it..
w
yea… there isn’t really a generic facility for that. in the past i had thought that it might be possible by replacing a single
@rule
with an intermediate provider of the output… but that’s doesn’t work for unions
(you’d have to wrap all of the implementations of the union)
how
@goal_rules
end up “chained” has in the past been to have some other goal depend on the same type (
BuiltPackage
, or whatever the input to the
package
goal ended up being)… but it’s odd in the case of
publish
because it’s `publish`’s sideeffect that you actually want to wait for.
c
So perhaps it is a dedicated hook that publish could offer specifically..
w
if
publish
had gone with “the side-effect is executed by `@rule`s” rather than “the side-effect is executed by the `@goal_rule`”, you could do that same thing here
So perhaps it is a dedicated hook that publish could offer specifically..
maybe…? i’m not sure that i see how to do it generically for a
@goal_rule
, given that it doesn’t actually produce anything
could generically hook `@rule`s based on their output types.
if i may: what does the hook you’re thinking of do?
c
Post data about what was built and published. Such as new version of app Demo//master v1.2.3
To trigger deployment etc..
w
mm
yea, probably not a good usecase for workunits.
could/should
publish
have optional structured output? e.g.
--json
, etc
c
That could work, yea
w
obviously the more we can do inside the framework, the better. but
c
I think the structured output could be made such, that it would also be possible to add in custom logic if desired, if the publish goal has a union for the results…
w
possibly, yea. having good lowest-common-denominator info on the
BuiltPackage
or publish’s output type would be good too.
c
I’ll toss something up tomorrow see what looks good and what not; ok? ;)
👍 1
w
i opened this thread because
BuiltPackage
might not include quite enough structured information yet
💯 1
yep
goodnight!
🙏 1
c
Yeah, I added a custom field with extra data already for the docker case