Re: [MTT devel] complaints about github pages being generated with every PR

2018-10-17 Thread Gilles Gouaillardet


each commits trigger a travis build, and the deploy section of travis 
builds the doc and push it if the html has changed

(the pdf contains timestamps, that's why we only focus on the html).

bottom line, the doc will be updated to gh-pages only if it has to.

If the gh-pages repo is updated at each commit and for no reason (e.g. 
the doc virtually did not change), then this is

a bug and I will be happy to investigate it.

fwiw, I manually double checked the last commits, and to me, the changes 
in the doc were legit.



On 10/18/2018 6:57 AM, Ralph H Castain wrote:

Tell the “certain individual” to get over it :-)

We’ve discussed this several times and it isn’t a simple fix. What we want is 
to regenerate when something actually changes in the generated files, but we 
don’t have a good way of doing it.

I’m sure we would be happy to see a PR from that “certain individual”  :-)

On Oct 17, 2018, at 2:50 PM, Howard Pritchard  wrote:

Hi Folks,

A certain individual is complaining about the fact that MTT repo currently
is set to have github pages updates following every commit.

I suspect fixing this requires intervention by someone with admin rights on the 

Could we have this feature disabled?


mtt-devel mailing list

mtt-devel mailing list

mtt-devel mailing list

Re: [MTT devel] Send results to multiple databases?

2017-12-20 Thread Gilles Gouaillardet

My 0.02 US$

An other approach would be to run the MTT tests, store the results in a 
(text ? xml ?) file,

and then submit them from an internet connected machine.

not only that would allow you to submit to multiple databases, but that 
would allow you to run

the MTT test suite on an cluster with no connection/proxy to internet.

I am not sure whether this is currently implemented by the perl and/or 
python clients.



On 12/21/2017 2:13 AM, Van Dresser, Daniel N wrote:

We have not tried this with the python client but I would expect it to work.  I 
will give it a test today and let you know the results and the syntax.


   -- Noah

-Original Message-
From: mtt-devel [] On Behalf Of 
Vallee, Geoffroy R.
Sent: Wednesday, December 20, 2017 8:49 AM
Subject: [MTT devel] Send results to multiple databases?


I am currently using the Perl client and 2 different databases: the one from 
the Open MPI community and a private ORNL-only database. With the current 
implementation of the Perl client, I cannot send the results to both databases. 
Is it something that is considered for the Python client? It would be extremely 
beneficial to me since a full test takes quite some time to run.

mtt-devel mailing list
mtt-devel mailing list

mtt-devel mailing list

[MTT devel] collecting OpenMPI info when the AlreadyInstalled module is used

2014-07-09 Thread Gilles Gouaillardet

i noticed that the bend-rsh cluster (Ralph from Intel ?) does not report :
- bitness
- endian
- compiler
- compiler version
- configure arguments
- vpath mode (to be confirmed)

i believe the root cause is MPI is not built via mtt since the
AlreadyInstalled module is used.

bitness can be retrieved from ompi_info in the Analyze phase.
that was trivial enough and i made a pull request for that :

other parameters (compiler, compiler version) could be "kind of"
retrieved with ompi_info
modulo some extra formatting to display it nicely.

i could not find any way to retrieve the configure command line. my best
bet would be to make it available
into OpenMPI so it can be retrieved.

i had some extra thoughts about #167 (Wrapper layer arount MTT client
for full parallelism : )
one implementation could generate several .ini files that use the
AlreadyInstalled module.
currently, this is not a good option because the parameters described
above are not reported to the mtt server.

Any thoughts ?



Re: [MTT devel] MTT: let's use git tags

2014-06-24 Thread Gilles Gouaillardet
+1 for using branches : branch usage is less error prone plus git makes
branching unexpensive.

as far as i am concerned, i'd rather have the default master branch is
the for the "stable" version
and have one branch called devel (or dev, or whatever) :
- git clone => get the stable (aka master) branch by default (safe by
- if you use the devel branch, one can only assume you know what you are
doing ...

That being said, tags on the master branch is a good practice



On 2014/06/25 2:33, Christoph Niethammer wrote:
> As an alternative idea: What about using branches to mark "stable" and 
> "development"?
> Tags are for fixed versions and so users will not receive updates unless they 
> update their update scripts manually?!
> When "development" is stable just merge into "stable".