-
Notifications
You must be signed in to change notification settings - Fork 424
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
Automatically pushing repos to sheds #50
Comments
I don't get a vote - but I would... encourage... getting just the master branch automatically pushed to to the test tool shed first and build confidence over several months that it is not going to interact poorly with "installable revisions". It is difficult to correct problems with the tool shed right (not unlike many package managers). |
fair point @jmchilton, I'd neglected to remember the pain of "installable revisions". I'll start pushing to the TTS and reopen this in a few months. |
+1 for pushing only to the TTS. |
+1 for testing the automated push approach extensively on TTS before moving on. MTS has to be protected because reverting stuff is unsolved (+unwanted) and IUC tools especially have high visibility. |
Thanks for the input y'all. I'm working on TTS pushing now (spoilers, there's stuff in master that's broken) though I'd like to leave MTS pushing in the roadmap. :) |
Please do leave it on the roadmap! I think Planemo is a good way to do this. |
Okay, we're automatically pushing to TTS now :D http://gx.hx42.org/job/TTS-Pusher/5/console Holy updates batman...I hope MTS isn't this bad.
|
if by 'bad' you mean 'behind' I am afraid it might be :) |
Good work with the automated push to the TTS. Automated deployment to the MTS seems like a good long term plan, but should we have any process in place to ensure tool versions are incremented (or just trust the Tool Shed revisions)? I'm particularly interested in functional changes (rather than documentation or cosmetic changes) which ought to result in a bump to the associated tool's revision number (and entry in any change log / version history in the README file). Whatever we decide could have implications on the contributing instructions (unless this housekeeping falls to the person doing a PR merge?). |
Question for @galaxyproject/iuc:
With planemo and the
-r
option, we can push the entire repo automatically to various places. I'd like to do this on a regular basis (as a jenkins job, every night or so), and I had a thought that I'd like to put to the IUC for comments.Originally I'd wanted to push master to the TTS, but then I realised that I wouldn't be able to test things in other branches I'm working on without explicit work on my end to push individual packages/branches.
Instead I'd like to propose:
My justification to automatically pushing master to the to MTS is that when things have been merged into master, they've been explicitly approved as a working package/tool by the IUC (otherwise they shouldn't be in master).
These would all be automated as a jenkins job, I can have it mail the IUC mailing list whenever things are updated if people would like to keep tabs on it.
Thoughts, comments, +/-1s?
The text was updated successfully, but these errors were encountered: