Is svg.juju.solutions down?

[Mark Shuttleworth]

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