cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <>
Subject [PROPOSAL] Minimum Viable CI Integration
Date Fri, 04 Mar 2016 00:54:55 GMT
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

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_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.



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