cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: github organisation cloudstack
Date Wed, 16 Mar 2016 19:59:57 GMT
The copying existing PRs would be for the purpose of running CI against it
in the context of being able to automate what happens next given the
result.

I am going to be putting time into fixing marvin tests and also merging in
any fixes to marvin to try to get the CI runs as bulletproof as possible.
I agree this is the first step towards being able to move forward with
being able to automate anything.

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Wed, Mar 16, 2016 at 3:55 PM, Sebastien Goasguen <runseb@gmail.com>
wrote:

> Will,
>
> I think you are putting the carriage before the horse, sort of speak.
>
> I would suggest you make a dummy PR to cloudstack/cloudstack (just one,
> let’s not talk about migration or anything like that).
>
> then you can use this as a playground to see how you could improve our CI…
>
> The main idea being that we have control of this fork and can test the
> hell out of it and github integration capability.
>
> for instance, I can create auto-builds of Docker images now, something I
> can’t do with apache/cloudstack…
>
> I think it is way too early to worry/think about moving existing PR there.
>
> -sebastien
>
> > On Mar 16, 2016, at 8:46 PM, Will Stevens <wstevens@cloudops.com> wrote:
> >
> > If we use this I think it's main purpose should be to facilitate CI and
> > integration testing of the apache/cloudstack repo.
> >
> > The first hurdle in using this repo for CI work is the fact that none of
> > the open PRs from apache/cloudstack are available in the
> > cloudstack/cloudstack repo.  If we are only using it for CI, that is not
> a
> > major problem because we can copy the PRs we care about from the
> > apache/cloudstack to the cloudstack/cloudstack repo programmatically.  I
> > have already built a POC script and have successfully been able to copy a
> > pull request from one repository to a different fork of the same repo.
> >
> > Some things to note when doing this (which probably won't be an issue if
> we
> > only use it for CI):
> > - The PR number in cloudstack/cloudstack will not reflect the PR number
> > from apache/cloudstack.  The apache/cloudstack PR number, author, etc
> could
> > be added to the body of the PR so we can easily navigate back to the
> > apache/cloudstack PR if we want to.
> > - The new PR in cloudstack/cloudstack will be owned by the person who
> runs
> > the copy pull request tool because it is their access token that is used
> to
> > create the new pull request.  Again, if this is only used for CI, thats
> not
> > a major problem as we can reference the original author in the issue body
> > for the PR when we copy it.
> > - None of the comments will be copied over with the PR when we copy it.
> > This again, probably is not a deal breaker if we are only using it for
> CI.
> > We could potentially loop through the original PR comments and add them
> to
> > the copy, but I am not sure that is worth it.  Again, they would all be
> > owned by the person who runs the tool, but we could again put the author
> in
> > the body.
> >
> > With this in mind, here are some of my ideas.
> >
> > We start by manually picking "mergeable" PRs that have at least 2 LGTM
> > votes and copying them to the cloudstack/cloudstack repo.  We then use
> the
> > hooks in Github to automatically runCI against that PR in the
> > cloudstack/cloudstack repo.  If the CI passes, then the code is
> > automatically merged into master and the official Apache repo is updated.
> > If it fails, the PR in cloudstack/cloudstack is updated with the status
> of
> > the CI run and the details.  A comment is then pushed to the
> > apache/cloudstack PR referencing the cloudstack/cloudstack PR and the CI
> > status for that PR.
> >
> > There are obviously many other potential ways to do something similar,
> but
> > these are some of my original thoughts.  We could also have it so that
> the
> > master is not automatically merged into the official master after the PR
> is
> > merged.  We could also have a nightly CI run against master and if that
> > passes, then and only then is the master pushed to the official apache
> > master.
> >
> > Anyway, let the discussions continue.
> >
> > BTW, apache has taken notice that we have created the cloudstack org:
> > https://github.com/apache/cloudstack/pull/1442
> >
> > *Will STEVENS*
> > Lead Developer
> >
> > *CloudOps* *| *Cloud Solutions Experts
> > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > w cloudops.com *|* tw @CloudOps_
> >
> > On Wed, Mar 16, 2016 at 4:13 AM, Erik Weber <terbolous@gmail.com> wrote:
> >
> >> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <
> daan.hoogland@gmail.com>
> >> wrote:
> >>
> >>> devs,
> >>>
> >>> There is a github organisation called cloudstack, to which we have more
> >>> control then to the apache/cloudstack repo on github. We need to decide
> >> as
> >>> community what to do with it.
> >>>
> >>> What are we going to do in this new organisation?
> >>>
> >>
> >> How about we test out different ways of improving our CI/other
> automation
> >> tasks, without the 'pressure' we have with the official repos?
> >> I.e. there is no pressure to get things merged, just test things out.
> >>
> >>
> >>> Will we let/ask Schuberg Philis to put cosmic in there?
> >>>
> >>
> >> No offence, but why would we do that? Cosmic != CloudStack. They already
> >> have what looks like a healthy github organization.
> >> If they want to help improve the CloudStack organization then fine, but
> >> lets not mix Cosmic into this.
> >>
> >>
> >>> Will be ask/let Will to run upr to it (so we don't depend on the
> >>> foundation)?
> >>>
> >>
> >> I don't see why not, let Will, SB, SBP, Accelerite (I have no clue how
> to
> >> spell it right yet), or whoever wants to, do automated testing on it.
> >> We need to figure out how we should grant access in a systematic way,
> but
> >> as Will explained in a different thread -- the permissions needed are
> >> non-intrusive and imho we should be generous handing them out to whoever
> >> wants/needs, and revert that grant if necessary
> >>
> >>
> >>> How will we sink it from/to apache or the apache github organisation?
> >>>
> >>
> >> I guess we still need to commit things to git-wip.a.o to keep doing
> commits
> >> the apache way, that would keep the ASF github fork in sync.
> >>
> >> --
> >> Erik
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message