You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <ma...@gmail.com> on 2016/12/12 20:57:01 UTC
[DISCUSS] EOL cordova-medic
Dearest cordova devs,
I'd like to discuss the possibility of killing off the cordova-medic
repo. Kinda funny, as I landed the first commit in that repo over 4
years ago.
I recently sent some updates in a pull request to medic [1], updating
some appium stuff, and after some discussion with Alex, he pointed out
that medic is pretty much not used these days. With paramedic taking
over as both the local testing tool as well as the keystone piece for
Cordova's CI on cloudapp, I don't think it is worth maintaining two
similar repositories with lots of code duplication between them.
It looks to me like Apache's buildbot configs for Cordova exist in the
medic repo. How valuable are these? Worth keeping around? Is execution
on Apache buildbot going to be a thing once more in the future?
Cloudapp seems to be doing an excellent job for us on its own...
Other than the buildbot configs, I believe the only thing that needs
to be migrated out are the Jenkins configs. This would be a beneficial
move for our CI system anyways, as right now every single Jenkins job
pulls down the medic repo _solely to get the Jenkins configs_. Moving
the Jenkins configs into the paramedic repo would save every cloudapp
job a repo pull, saving some time, and in CI, every second counts :)
Anything else I'm missing? What do y'all think? Good idea? Bad idea?
Thanks for your feedback!
-Fil
[1] https://github.com/apache/cordova-medic/pull/106
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] EOL cordova-medic
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
Hey all!
I’m +1 for killing Medic, since it hasn’t been used for months and I guess hardly ever will be used in the future.
Though I have a bit different proposal about moving configs – IMO they are a part of CI and should live somewhere inside a CI. I don’t think there is a need to either exhibit them to public or make them easily editable by anybody – the current practice demonstrates that the only one who really needs to see or edit these configs is the CI maintainer. From the implementation side, I think we can just reuse one of the millions of Jenkins plugins (maybe this: https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin)
> Substantial code was added to paramedic to support some other use cases (Appium, Sauce, ...), but I would still REALLY like to prevent us turning paramedic into a behemoth travelling hospital ... it may already be too late though.
Jesse, I share your concerns! Just want to say that despite it became really complex, and the code is far from ideal, paramedic really does its job!
I wish we could have a bit of spare time and some free hands to redesign it and make it lightweight and modular (I think all that added functionality, like Appium and Sauce support, easily could be moved out of paramedic into “plugins”)
-
Best regards, Vladimir
On 12/13/16, 01:03, "Filip Maj" <ma...@gmail.com> wrote:
On Mon, Dec 12, 2016 at 1:46 PM, Jesse <pu...@gmail.com> wrote:
> What would be the added responsibilities for cordova-paramedic?
Good question. As far as I can tell, I believe paramedic would need to
additionally house the helper JSON files containing configuration that
one passes into paramedic - basically replacing the various flags one
can run paramedic with with a single one pointing to a file instead.
In particular, the Jenkins configs that the cloudapp CI uses that it
feeds into paramedic [1] - including the "local" ones used for local
testing [2], which seem particularly relevant to paramedic's mission.
This would save our Jenkins instance from pulling the medic repo down,
speeding up test execution (it seems silly to clone a whole repo just
to pull a few JSON files out!).
So right now, when I want to run paramedic locally, I invoke something like:
$ node cordova-paramedic/main.js --platform android --plugin
./cordova-plugin-contacts --verbose --cleanUpAfterRun
I can reduce on the flags passed in by pointing paramedic to the
afore-mentioned local configs, but, these currently exist in the medic
repo. So I've actually been running paramedic recently like so:
$ node cordova-paramedic/main.js --plugin
./cordova-plugin-contacts --config
./cordova-medic/jenkins-conf/pr/local/android-5.1.config.json
The above incantation is also how our cloudapp CI invokes paramedic:
by pointing it to a config file (it points it to a "non-local" config
file, e.g. [3]).
In effect, it is just shuffling around code from one repo to the
other, but the benefits we get are:
- save compute within our CI
- all testing-relevant configurations will exist in one repo, not two
- we can remove the medic repo along with its code duplication of paramedic
The cons, as far as I can tell, are:
- there will be a new 'config' top-level directory
Let me know how that sounds and what else I've missed.
[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-medic%2Ftree%2Fmaster%2Fjenkins-conf&data=02%7C01%7Cv-vlkoti%40microsoft.com%7C2e9fcdbcd93d4516275708d422dab62e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171770130218288&sdata=YjWqa5CiRntxkhmikqNE12bwGaEf0W4q2YF%2BT8E1Asg%3D&reserved=0
[2] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-medic%2Ftree%2Fmaster%2Fjenkins-conf%2Fpr%2Flocal&data=02%7C01%7Cv-vlkoti%40microsoft.com%7C2e9fcdbcd93d4516275708d422dab62e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171770130218288&sdata=FbkW3oVkKBw%2FrlPTc3wUCD5d3dRdTYDvYPTj1h%2FUYRM%3D&reserved=0
[3] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-medic%2Fblob%2Fmaster%2Fjenkins-conf%2Fpr%2Fandroid-5.1.config.json&data=02%7C01%7Cv-vlkoti%40microsoft.com%7C2e9fcdbcd93d4516275708d422dab62e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636171770130218288&sdata=BqBTYje0DLo2ND6SPxkLTcgyI1c0HA0qSoXS7%2FhdVw8%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] EOL cordova-medic
Posted by Filip Maj <ma...@gmail.com>.
On Mon, Dec 12, 2016 at 1:46 PM, Jesse <pu...@gmail.com> wrote:
> What would be the added responsibilities for cordova-paramedic?
Good question. As far as I can tell, I believe paramedic would need to
additionally house the helper JSON files containing configuration that
one passes into paramedic - basically replacing the various flags one
can run paramedic with with a single one pointing to a file instead.
In particular, the Jenkins configs that the cloudapp CI uses that it
feeds into paramedic [1] - including the "local" ones used for local
testing [2], which seem particularly relevant to paramedic's mission.
This would save our Jenkins instance from pulling the medic repo down,
speeding up test execution (it seems silly to clone a whole repo just
to pull a few JSON files out!).
So right now, when I want to run paramedic locally, I invoke something like:
$ node cordova-paramedic/main.js --platform android --plugin
./cordova-plugin-contacts --verbose --cleanUpAfterRun
I can reduce on the flags passed in by pointing paramedic to the
afore-mentioned local configs, but, these currently exist in the medic
repo. So I've actually been running paramedic recently like so:
$ node cordova-paramedic/main.js --plugin
./cordova-plugin-contacts --config
./cordova-medic/jenkins-conf/pr/local/android-5.1.config.json
The above incantation is also how our cloudapp CI invokes paramedic:
by pointing it to a config file (it points it to a "non-local" config
file, e.g. [3]).
In effect, it is just shuffling around code from one repo to the
other, but the benefits we get are:
- save compute within our CI
- all testing-relevant configurations will exist in one repo, not two
- we can remove the medic repo along with its code duplication of paramedic
The cons, as far as I can tell, are:
- there will be a new 'config' top-level directory
Let me know how that sounds and what else I've missed.
[1] https://github.com/apache/cordova-medic/tree/master/jenkins-conf
[2] https://github.com/apache/cordova-medic/tree/master/jenkins-conf/pr/local
[3] https://github.com/apache/cordova-medic/blob/master/jenkins-conf/pr/android-5.1.config.json
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] EOL cordova-medic
Posted by Jesse <pu...@gmail.com>.
What would be the added responsibilities for cordova-paramedic?
I am all about deleting code, but if we are simply reshuffling
responsibilities then we are really not gaining/losing anything.
Originally, and metaphorically ...
'medic' was the hospital and 'paramedic' was the ambulance.
To elaborate, for those who don't get metaphors
medic was meant to test all the things
paramedic was meant to quickly test any simple combo of a plugin+platform
Substantial code was added to paramedic to support some other use cases
(Appium,Sauce,...), but I would still REALLY like to prevent us turning
paramedic into a behemoth travelling hospital ... it may already be too
late though.
@purplecabbage
risingj.com
On Mon, Dec 12, 2016 at 1:31 PM, Steven Gill <st...@gmail.com> wrote:
> +1
>
> On Mon, Dec 12, 2016 at 10:57 AM, Filip Maj <ma...@gmail.com> wrote:
>
> > Dearest cordova devs,
> >
> > I'd like to discuss the possibility of killing off the cordova-medic
> > repo. Kinda funny, as I landed the first commit in that repo over 4
> > years ago.
> >
> > I recently sent some updates in a pull request to medic [1], updating
> > some appium stuff, and after some discussion with Alex, he pointed out
> > that medic is pretty much not used these days. With paramedic taking
> > over as both the local testing tool as well as the keystone piece for
> > Cordova's CI on cloudapp, I don't think it is worth maintaining two
> > similar repositories with lots of code duplication between them.
> >
> > It looks to me like Apache's buildbot configs for Cordova exist in the
> > medic repo. How valuable are these? Worth keeping around? Is execution
> > on Apache buildbot going to be a thing once more in the future?
> > Cloudapp seems to be doing an excellent job for us on its own...
> >
> > Other than the buildbot configs, I believe the only thing that needs
> > to be migrated out are the Jenkins configs. This would be a beneficial
> > move for our CI system anyways, as right now every single Jenkins job
> > pulls down the medic repo _solely to get the Jenkins configs_. Moving
> > the Jenkins configs into the paramedic repo would save every cloudapp
> > job a repo pull, saving some time, and in CI, every second counts :)
> >
> > Anything else I'm missing? What do y'all think? Good idea? Bad idea?
> >
> > Thanks for your feedback!
> >
> > -Fil
> >
> > [1] https://github.com/apache/cordova-medic/pull/106
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: [DISCUSS] EOL cordova-medic
Posted by Steven Gill <st...@gmail.com>.
+1
On Mon, Dec 12, 2016 at 10:57 AM, Filip Maj <ma...@gmail.com> wrote:
> Dearest cordova devs,
>
> I'd like to discuss the possibility of killing off the cordova-medic
> repo. Kinda funny, as I landed the first commit in that repo over 4
> years ago.
>
> I recently sent some updates in a pull request to medic [1], updating
> some appium stuff, and after some discussion with Alex, he pointed out
> that medic is pretty much not used these days. With paramedic taking
> over as both the local testing tool as well as the keystone piece for
> Cordova's CI on cloudapp, I don't think it is worth maintaining two
> similar repositories with lots of code duplication between them.
>
> It looks to me like Apache's buildbot configs for Cordova exist in the
> medic repo. How valuable are these? Worth keeping around? Is execution
> on Apache buildbot going to be a thing once more in the future?
> Cloudapp seems to be doing an excellent job for us on its own...
>
> Other than the buildbot configs, I believe the only thing that needs
> to be migrated out are the Jenkins configs. This would be a beneficial
> move for our CI system anyways, as right now every single Jenkins job
> pulls down the medic repo _solely to get the Jenkins configs_. Moving
> the Jenkins configs into the paramedic repo would save every cloudapp
> job a repo pull, saving some time, and in CI, every second counts :)
>
> Anything else I'm missing? What do y'all think? Good idea? Bad idea?
>
> Thanks for your feedback!
>
> -Fil
>
> [1] https://github.com/apache/cordova-medic/pull/106
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>