Open dansanduleac opened 6 years ago
Thanks for the feedback. I think this is probably reasonable -- I took a quick look, and it looks like this does end up getting overridden in many of our existing repos (https://github.com/palantir/distgo/blob/master/.circleci/config.yml#L115, https://github.com/palantir/godel-dep-plugin/blob/master/.circleci/config.yml#L99), which points to the defaults not being great.
The fix would likely be for --product
not to be auto-populated -- although conceptually using the "GitHub project name" might make sense, the tool currently doesn't make any assumptions about code being hosted on GitHub, and I don't want to add in that assumption/dependency.
This logic breaks (e.g. circleci) on multi-project repos like go-java-launcher (publishing both
go-java-launcher
andgo-init
) because it tries to derive the bintray package from each project's name, whereas it should probably be derived from the github project's name - that's what we do for OSS java projects. See bintray api re: uploading content. Also we probably shouldn't call this Product in the bintray config, we should model the API terminology.Had to publish manually using ssh by passing in the
--product
like so:Also, we seem to get back a 400 when adding artifact to Bintray downloads list, could that be because we are somehow publishing two packages to the same identifier in bintray? It might also be a red herring since we may have already added
go-java-launcher 1.4.0
to the downloads list in the build linked at the top that failed.. but I don't see any logs about that to confirm or deny it.cc @robert3005 who helped me debug