cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Kotikov (Akvelon)" <>
Subject Re: [DISCUSS] EOL cordova-medic
Date Tue, 13 Dec 2016 07:30:37 GMT
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

> 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" <> wrote:

    On Mon, Dec 12, 2016 at 1:46 PM, Jesse <> 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
    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.
    To unsubscribe, e-mail:
    For additional commands, e-mail:

View raw message