Yes, I have most of it already built and will be releasing it later today
or over the weekend.  The reason I chose Golang is because it can be cross
compiled to be run on any system and distributed as a single binary with no
dependencies.  This means that no one will have to worry about building it
or having to change their environment at all in order to use it.  I am
trying to lower the barrier to entry and make it as easy as possible for
people to contribute back their CI execution details.

*Will STEVENS*
Lead Developer

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

On Fri, Mar 4, 2016 at 8:53 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> 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 <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
> >
>
>
>
> --
> Daan
>

Reply via email to