Switching to Tarmac

[roger peppe]

On 12 June 2013 06:59, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone-
>
> I think we're finally at the point where the juju-core test suite will
> pass cleanly on Tarmac, and I'd like us to switch over to using it for
> landing code.

This sounds great! Thanks for putting in the work needed to make it
happen.

>   a) Go to the Launchpad merge proposal page, mark the whole proposal
>      Approved. Make sure there is a "Commit Message" set (rather than
>      just a description)

Should we just copy the entire description to the commit message?
That would seem like a sensible default to me - I very much like having
the whole description and link to the code review in the main commit
log.

>   b) Install Aaron Bentley's lp:rv-submit as a Bazaar plugin, and use
>      'bzr rv-submit', which will check for 2 LGTMs in the comments and
>      do the steps in (a) for you.[1]
>
> 3) The bot wakes up every minute to look for changes, and the test
> suite takes <15 minutes to run. If the test suite fails, the bot puts
> the results back on to the Launchpad merge proposal and sets the
> status back to Needs Review. So if you haven't heard anything, there
> may be a problem with the submission (biggest current problem is
> Commit Message missing, which tends to just silently ignore the MP
> until you set one.)
>
> Note that if the bot is busy, it will only run 1 request at a time. So
> if there is a queue, it make take longer than 15 minutes.

If I've got one branch that is dependent on several others,
is there a way to make sure that it is merged after them,
or do I have to manually wait until the previous branches
have landed?

> 4) We will remove running the juju-core test suite as a prerequisite
> for landing lp:goose changes. (We still don't have dependency
> tracking, so landing code in a dependency can break landing code in
> juju-core, but we still need some way to land a patch and land the
> patch that fixes juju-core.)
>
> 5) Right now the 'test' in Tarmac is:
>   go fmt ./... && go build ./... && go test ./...

To save a few seconds, I'd suggest that it should be "go install ./..."
rather than "go build ./...".

> Which means that it doesn't yet automatically update dependencies. I'm
> looking to change it to something that builds a pristine GOPATH every
> time (using a shared repository to avoid having to actually download
> the code each time).
>
> Along the way, I'm hoping we can get dependency tracking, so that it
> doesn't build from TIP of everything each time.
>
> 6) When we get Continuous Integration (from a Jenkins instance), I'll
> want to add a job that grabs TIP of everything so we know what it will
> take to keep things on HEAD. (eg, we can be told that the last change
> to goose/mgo/go.crypto will break juju-core, so we can prepare a patch
> etc.)
>
> 7) The bot will be running go 1.0.3 on Precise for now, as I expect
> that is the platform that we'll find the easiest to break
> accidentally. (And is also likely to be the platform that most charms
> will be running on.)
>
> 8) When we get things like GOMAXPROCS=2 and the test suite working
> reliably, I will be happy to set that in the bot so that we can
> ratchet up our baseline. Flaky tests (things that fail once in a
> while) will be pretty ruthlessly disabled. I never want us to feel
> like you should just resubmit without modifications to get code to land.

What's the plan with respect to live tests? I'd love to have some
assurance that things still work on the various possible
providers.

> 9) I will add people's SSH keys to go-bot's account, so that we have a
> workaround when the bot is being rude/broken/etc.

my ssh public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDOjaOjVRHchF2RFCKQdgBqrIA5nOoqSprLK47l2th5I675jw+QYMIihXQaITss3hjrh3+5ITyBO41PS5rHLNGtlYUHX78p9CHNZsJqHl/z1Ub1tuMe+/5SY2MkDYzgfPtQtVsLasAIiht/5g78AMMXH3HeCKb9V9cP6/lPPq6mCMvg8TDLrPp/P2vlyukAsJYUvVgoaPDUBpedHbkMj07pDJqe4D7c0yEJ8hQo/6nS+3bh9Q1NvmVNsB1pbtk3RKONIiTAXYcjclmOljxxJnl1O50F5sOIi38vyl7Q63f6a3bXMvJEf1lnPNJKAxspIfEu8gRasny3FEsbHfrxEwVj
rog at rog-x220

  cheers,
    rog.