cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [PROPOSAL] Minimum Viable CI Integration
Date Fri, 04 Mar 2016 13:53:29 GMT
Will, Do you have an implementation of notify-pr? I am asking as you
specify it will be implemented in golang which seems odd. It is not amongst
the 7 or so languages already in use.

On Fri, Mar 4, 2016 at 1:54 AM, Will Stevens <>

> 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


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