Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

post test results to publicly available URL #2

Open
gregcaporaso opened this issue Sep 6, 2012 · 13 comments
Open

post test results to publicly available URL #2

gregcaporaso opened this issue Sep 6, 2012 · 13 comments

Comments

@gregcaporaso
Copy link
Contributor

Would be really cool if the tests results that get emailed also were posted to the internet somewhere. Could use GitHub pages for this. If we were going to do that, we could probably also post updates to the developer documentation on a nightly basis.

@wasade
Copy link

wasade commented Sep 6, 2012

Agree

On Thu, Sep 6, 2012 at 11:06 AM, Greg Caporaso [email protected]:

Would be really cool if the tests results that get emailed also were
posted to the internet somewhere. Could use GitHub pages for this. If we
were going to do that, we could probably also post updates to the developer
documentation on a nightly basis.


Reply to this email directly or view it on GitHubhttps://github.com/qiime-dev/automated_testing/issues/2.

@jairideout
Copy link
Contributor

Looking into this a bit- what do you guys think about posting testing results on the Clout wiki? We could have a section for each project, and each section would have a list ordered by date with links to the results.

If other people started using Clout, they could optionally post their testing results to their own wikis.

@jairideout
Copy link
Contributor

Some more info: the current size of the nightly test results is around 0.5MB. If we were to use the wiki to host these results, it would take us around 5.5 years to reach GitHub's 1GB recommended repo size limit. Seems pretty reasonable, and if we start running out of space, we could always archive older test results.

@wasade
Copy link

wasade commented Feb 21, 2013

0.5MB tar gz'd?

@wasade
Copy link

wasade commented Feb 21, 2013

ah...

@jairideout
Copy link
Contributor

0.5MB not zipped (7 plain text files, excluding the complete log). We could store them in .tar.gz format, but I was thinking it'd be cool if they could be directly viewable online from within a web browser.

@gregcaporaso
Copy link
Contributor Author

I definitely think it'd be good to have them viewable from a browser. What about storing them on the AWS-based web server that you're going to build?

@jairideout
Copy link
Contributor

We could do that, but I like the wiki idea better, since Clout and most of the projects that it's testing are on GitHub already. That way, the testing results will also be on GitHub, under version control (in the wiki repo, which is separate from the main one), and storage/hosting is free.

We could add the ability to automatically post results to a GitHub wiki, or (optionally) store them on the machine that runs Clout.

Do you see issues with the wiki approach versus hosting them from our new web server?

@gregcaporaso
Copy link
Contributor Author

Would the user specify which project they live under? I don't think we'd want other people's projects to show up under clout. I do worry a little about making it too GitHub specific.

@jairideout
Copy link
Contributor

In the config file there'd be a way to (optionally) specify what wiki (and where) to place the results. We'd most likely add results for all of the current projects being tested on a nightly basis (e.g. QIIME, PyCogent, etc.) since they are all related bioinformatics software.

If there's an option to support a GitHub wiki and/or just save to disk, would this get around the issue of being too GitHub-specific?

@gregcaporaso
Copy link
Contributor Author

If there's an option to support a GitHub wiki and/or just save to disk, would this get around the issue of being too GitHub-specific?

Yes, definitely - then they could just define another cron job to poll for new files and do something with them.

@gregcaporaso
Copy link
Contributor Author

So I think you should go ahead with this solution.

@jairideout
Copy link
Contributor

Great, thanks for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants