Will, I guess Bharat has something similar in working. Bharat, Can you please elaborate your approach for sharing the CI results with community ?
Thanks, Srinivas On Fri, Mar 4, 2016 at 6:28 AM, Will Stevens <williamstev...@gmail.com> wrote: > Apparently attached files don't work when sending to the mailing list. > > Find the screenshot here: > > https://objects-east.cloud.ca/v1/5ef827605f884961b94881e928e7a250/swill/Screen%20Shot%202016-03-03%20at%207.53.42%20PM.png > > On Thu, Mar 3, 2016 at 7:54 PM, Will Stevens <williamstev...@gmail.com> > wrote: > > > Hey Everyone, > > As I am sure most of you are aware, I have been focusing a lot on ways to > > get CI integrated back into the community. > > > > Today I build a little POC to validate some ideas and get a feel for a > > potential approach for getting CI integrated into the Github pull request > > workflow. > > > > There are multiple individuals/companies focusing on CI right now (which > > is a good thing), but there has not really been much discussion (that I > am > > aware of) for how these different CI runs will push back results to the > > community. I want to make sure that nobody's work on this topic goes to > > waste, so my goal is to provide a simple and consistent way for everyone > to > > push their results back to the community. > > > > Here is the basic idea (please give feedback): > > - A simple cross platform command line tool with zero dependencies will > be > > provided (and open sourced) which will handle the submission of the CI > > results back to the community. It is written in Golang and is currently > > called 'notify_pr'. > > - At the end of a CI execution, the CI should automate the execution of > > this tool to handle updating the appropriate PR with the results. > > > > Configuration can be done via the command line or through an INI file. > > Here is an example of the configuration details. The commit is the > > commit that the CI just executed against. > > > > token = <your github token> > > owner = apache > > repo = cloudstack > > commit = c8443496d3fad78a4b1a48a0992ce545bde299e8 > > > > summary_file = <a text file summary of the run> > > full_detail_dir = <a directory structure to be recursively uploaded to > > object store> > > full_detail_files = <a comma separated list of files to upload to object > > store> > > store_api = <swift or s3> > > store_endpoint = <url endpoint> > > store_identity = <keystone identity or aws access key> > > store_secret = <keystone password or aws secret key> > > > > I have not yet implemented the object storage endpoints, but I have code > > to do it from a different project, so I just need to add it. I will be > > able to host my CI output in a swift object store, but others may need to > > use AWS S3. Maybe we can get sponsorship for this storage. We will only > > keep the logs for a window of like a week or so on the object store so > the > > storage usage will not be ever growing. > > > > Basically, the tool takes the details of the repository you are > validating > > a Pull Request for and the commit you are building. It also takes the > > files you would like to push to the pull request. The summary file will > be > > shown as text in the pull request comment and the other files will be > > uploaded to an object store and will be publically available for a period > > of time (probably about a week and then get cleaned up, details TBD). > The > > files to be uploaded to object store could be either specified as > > individual files, OR a target directory and all the files in that > directory > > will be recursively uploaded to the object store. > > > > When the tool is run, it will scan through all the open pull requests in > > the target repository and when it finds the pull request corresponding to > > the commit in question, it will post the details as a comment to that > pull > > request. This functionality is currently working (see the attached > > screenshot). I can change the formatting and such, this is just an > example. > > > > This is still a very rough concept that I have only worked on for a day, > > but hopefully you guys agree that it is a good start towards a consistent > > feedback mechanism for the community to take advantage of the different > > distributed CI installations. > > > > Please voice your feedback and concerns. I am sure I have not thought of > > everything and we may still want to make fundamental changes to the > > approach, but I think the concept is solid. > > > > Cheers, > > > > Will > > >
