On 15/06/16 14:02, Merlijn Sebrechts wrote: > Awesome! > > What's the recommended approach for the test bundles? These bundles > should use the latest non-published dev version of the Charm. Is there > a way to specify this in the bundle or should I recreate the bundle > after each push?
I think we will adopt some of the nice conventions from the snap world for charms, but I'll let the team talk to timelines :) Here's how it works in the snap world. When you push you get a revision (that's implemented today). You might have a stable branch and a trunk branch, and if you alternate pushes between them you just get different revisions, but a higher revision is not necessarily a higher branch of the software, it's just a different revision. So 'latest revision' is a bad idea to specify, because it jumps between beta, trunk, stable etc. Separately, then, you can "release" a revision into a channel. So you say "release this revision into the beta channel". You have edge, beta, candidate and stable channels for any snap. They don't HAVE to be populated, and if you ask for a channel that is not populated it will give you the next less-risky option (i.e. if you ask for beta and there is no beta but there is a candidate, you'll get the candidate). In this world, you would push your branch and do a test of that revision in isolation. But you could have a bundle that specified the edge channel, and if your revision-tests pass then you'd release that revision to the edge channel, and that would then be picked up in your bundles. This is (almost) an answer to your question, because you still have to consciously release that revision into edge for it to be picked up by your test bundle. But I think it works fine - you manually test the charm itself based on the revision, and then your bundles will test it as part of various topologies when you release it to edge. Would that make sense? Mark -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
