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 <run...@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 <wstev...@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 <terbol...@gmail.com> wrote: > > > >> On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland < > daan.hoogl...@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 > >> > >
