search

juju-solutions / layer-cwr

Layer for building the Juju Jenkins CI env
Other
2 stars 5 forks source link

Use sane bundle names on result page. #120

Open seman opened 7 years ago

kwmonroe commented 7 years ago

@seman i don't think you could be less descriptive if you tried! What's the insane thing you're seeing, and what's the sane thing you want?

seman commented 7 years ago

Just saying instead of cwr_charm_commit_mysql_in_cs_wiki_simple, change the name to wiki-simple on result page (image #1). Also when clicking on the bundle name on "report.html" (image #2), it should link back to the bundle in charmstore or repository.

sf

s3

kwmonroe commented 7 years ago

Just saying instead of cwr_charm_commit_mysql_in_cs_wiki_simple, change the name to wiki-simple

I'm not a fan of that because what if you want to test mediawiki in the same bundle context? I think it's nice that you'd have both:

cwr_charm_commit_mediawiki_in_cs_wiki_simple
cwr_charm_commit_mysql_in_cs_wiki_simple

So you'd know exactly what the charm and bundle context is being executed by the job name.

clicking on the bundle name on "report.html" should link back to the bundle in charmstore or repository.

Agreed. How does cwr.jujucharms.com do that? I assumed the report.html page was written by cloud-weather-report, but I'm not sure how it knows where to link.

johnsca commented 7 years ago

I, too, really dislike the underscore-heavy presentation in the reports, but between the collision issue that @kwmonroe mentioned and the need to be able to match jobs up to the output directory in a consistent manner, I couldn't come up with a better way to have them be presented nicely without the underscores and namespacing.

Things to consider: being able to see a job in the CWR report and being able to easily match that job up in Jenkins, being able to reference said job in the API, being able to distinguish jobs that use the same bundle but are building and testing different specific charms within the bundle, avoiding corner cases where special characters in the title leak out and break things on the file system, avoiding a lot of duplicate logic throughout the codebase for normalizing titles to jobs names, etc.

But if we can come up with a solution that improves the presentation while addressing those issues, I'm all for it.