What's with all the test talk? (aka, give me CI already)

Mon Dec 12 12:38:28 UTC 2016

I'm just not sure what the best approach would be. My idea is that our CI
system will push directly to stable. However, I think it's best if the
charms are only pushed to stable when both the Charm tests and bundle tests
succeed. So maybe after charm tests, the charms are pushed to edge, and
when the bundle tests succeed both the bundles and the charms are pushed to
stable?

2016-12-12 11:17 GMT+01:00 Konstantinos Tsakalozos <
kos.tsakalozos at canonical.com>:

> This workflow sounds reasonable. One question, why are you using only the
> edge channel?
>
> Thanks
>
> On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts <
> merlijn.sebrechts at gmail.com> wrote:
>
>> The workflow that we'd like to have is very similar to what you do with
>> the charms. The first steps are already possible with `bundle-cwr-ci`:
>>
>>    - If a new charm version is committed, run the tests of that charm.
>>    - If the tests succeed, push the charm to edge.
>>
>> We save our bundles on Github with revision-less charm urls. A push of a
>> charm to the edge channel should trigger a job that does the ci for the
>> bundle:
>>
>>    - Add the latest revision to all revision-less charm urls. (If they
>>    do have a revision specified, leave them be.)
>>    - Run bundletester on the resulting bundle.
>>    - If tests succeed, push the bundle to edge.
>>
>> What do you think of this workflow?
>>
>> Our workflow in the past was a lot more complex, but moving to MAAS
>> allowed us to greatly simplify it.
>>
>>
>>
>> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos <
>> kos.tsakalozos at canonical.com>:
>>
>>> Hi Merlijn,
>>>
>>> Building/testing/releasing bundles from the CI is in our future tasks.
>>>
>>> Some time ago you posted on this list a script to update bundles in
>>> light of charm updates. We will have to take a closer look in the way
>>> bundles are handled in your case. Any feedback is much appreciated.
>>>
>>> Thanks,
>>> Konstantinos
>>>
>>> On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts <
>>> merlijn.sebrechts at gmail.com> wrote:
>>>
>>>> This is awesome!
>>>>
>>>> >  I have a nasty habit of committing straight to master, so bear with
>>>> us as development is moving fast at the moment.
>>>>
>>>> If only you could have a CI system to test your bundles
>>>> automatically... ;)
>>>>
>>>> 2016-12-08 19:36 GMT-05:00, Kevin Monroe <kevin.monroe at canonical.com>:
>>>> > Hi Juju!
>>>> >
>>>> > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author
>>>> Workflows
>>>> > [3], you'd think December was the month we all remembered the
>>>> importance of
>>>> > software testing.  There are oodles of test tools for charms/bundles,
>>>> and
>>>> > if you know about all of them, you're probably putting out thoughtful,
>>>> > well-tested charms (thanks stub!).
>>>> >
>>>> > One thing that we've found missing is a nice charm CI/CD system that
>>>> > leverages these tools to automatically give developers confidence in
>>>> their
>>>> > code and handle the release cycle from a source repo to the charm
>>>> store,
>>>> > soup to nuts.  Wouldn't it be nice if you could commit a charm update
>>>> to
>>>> > github and automatically have Cloud Weather Report kick off Jenkins
>>>> jobs on
>>>> > all your clouds, which in turn called Bundletester to handle
>>>> deployment,
>>>> > which in turn called Amulet and Matrix to run specific tests?  Taking
>>>> it a
>>>> > step further, it'd be nice if that system could automatically push
>>>> > charms/bundles to your edge channel (if their tests pass), and if you
>>>> tag
>>>> > source with a release tag, build/test/release it to your stable
>>>> channel.
>>>> >
>>>> > This kind of system is what the Big Software team has been working on
>>>> > recently, and we're open to feedback!  Our goal is to deliver a
>>>> system (as
>>>> > a bundle) that answers the question, "how should I do CI/CD for my
>>>> charms
>>>> > and bundles?"  We're also working on a variation that includes the
>>>> Review
>>>> > Queue -- it will eventually become the brains behind
>>>> > https://review.jujucharms.com and will be available for anyone
>>>> wanting a
>>>> > CI/CD + Source Review system in-house.
>>>> >
>>>> > If you're interested, development is happening at
>>>> > https://github.com/juju-solutions/bundle-cwr-ci.  Have a look at the
>>>> readme
>>>> > for more details and let us know what you think.  The bundle yaml
>>>> files are
>>>> > currently deployable, buy I have a nasty habit of committing straight
>>>> to
>>>> > master, so bear with us as development is moving fast at the moment.
>>>> Watch
>>>> > this space for updates on our progress.
>>>> >
>>>> > [0] - https://lists.ubuntu.com/archives/juju/2016-December/008260.
>>>> html
>>>> > [1] - https://lists.ubuntu.com/archives/juju/2016-December/008287.
>>>> html
>>>> > [2] - https://lists.ubuntu.com/archives/juju/2016-December/008288.
>>>> html
>>>> > [3] - https://lists.ubuntu.com/archives/juju/2016-December/008302.
>>>> html
>>>> >
>>>> > Thanks!
>>>> > --
>>>> > Kevin Monroe
>>>> >
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161212/710d4454/attachment.html>