cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <>
Subject Re: github organisation cloudstack
Date Wed, 16 Mar 2016 19:46:45 GMT
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

Anyway, let the discussions continue.

BTW, apache has taken notice that we have created the cloudstack org:

Lead Developer

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

On Wed, Mar 16, 2016 at 4:13 AM, Erik Weber <> wrote:

> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland <>
> 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

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