Re: [MTT devel] complaints about github pages being generated with every PR
Howard, 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. Cheers, Gilles 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” :-) Ralph 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 repo. Could we have this feature disabled? Howard ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel
Re: [MTT devel] Send results to multiple databases?
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. Cheers, Gilles 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. Thanks, -- Noah -Original Message- From: mtt-devel [mailto:mtt-devel-boun...@lists.open-mpi.org] On Behalf Of Vallee, Geoffroy R. Sent: Wednesday, December 20, 2017 8:49 AM To: mtt-devel@lists.open-mpi.org Subject: [MTT devel] Send results to multiple databases? Hello, 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. Thanks, ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/mtt-devel
[MTT devel] collecting OpenMPI info when the AlreadyInstalled module is used
Folks, 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 : https://github.com/open-mpi/mtt/pull/1 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 : https://svn.open-mpi.org/trac/mtt/ticket/167 ) 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 ? Cheers, Gilles
Re: [MTT devel] MTT: let's use git tags
Jeff, What i meant by "less error prone" is "you use the stable branch by default" so you do not checkout the dev/unstable branch by default. as you pointed, the level/frequency of MTT development is fairly low, my idea would be to create a "dev" branch, and when the state of the dev branch is "production ready", simply do a git checkout master git merge dev that being said, i am far from mastering git and i cannot judge the pros vs cons of this (merge) versus the fast forward approach pointed by Christoph Cheers, Gilles On 2014/06/27 16:11, Christoph Niethammer wrote: > +1, for a stable branch which is *fast forwarded* to master when changes are > confirmed to work. > PS: Tags are intended to be static and not moved around in git as Dave says, > instead you can sign them using gpg fortifying them even more. ;) > > - Original Message - > From: "Dave Goodell (dgoodell)" > To: "Development list for the MPI Testing Tool" > Sent: Thursday, June 26, 2014 2:47:35 PM > Subject: Re: [MTT devel] MTT: let's use git tags > > Published Git tags are *not* movable (by design). You're better off making it > a branch that you treat like a tag, if that's your desire. Even then, you > might confuse someone who is less familiar with Git in some cases if you move > that branch around. > > -Dave > >> On Jun 26, 2014, at 6:06 AM, "Jeff Squyres (jsquyres)" >> wrote: >> >> I've thought about this a little, and I'm still inclined to use the >> simple/lazy method of tags on master. Some random points, in no particular >> order: >> >> 1. master should always be for development, IMHO. If we start using a >> multi-branch scheme, then the branches should be for releases, etc. >> >> 2. MTT has always been distributed by VCS; we've never made discrete >> distributions (e.g., a tarball). As such, I'm comfortable labeling it as a >> bit "different" than how most other software is delivered -- e.g., using git >> tags on master is "good enough". >> >> 3. The level/frequency of MTT development is fairly low; it would be good to >> keep the bar as low as possible for amount of work required to deploy a new >> feature to the OMPI community for MTT testing. Meaning: a new feature or >> bug fix pops up in MTT every once in a while -- we generally don't have >> commits that are being developed and merged to a release series in an >> out-of-order fashion. So doing a few commits for a new feature/bug fix and >> then tagging the result is fine/good enough. If there *are* interleaved >> commits of multiple new features/bug fixes, we can simply wait until all are >> done before tagging. >> >> 4. I realize this scheme is not as flexible as a release branch (where you >> can merge new features/bug fixes out of order), but the level of MTT >> development is so low that I'd prefer the slightly-simpler model of just >> tagging (vs. merging/etc.). >> >> 5. I'm not sure how using a release branch is less error-prone...? I >> understand git branching is cheap, but if we have a separate branch, then we >> either need to remember to cherry-pick every commit we want or we have to >> continually merge from master->release_branch. Seems like more work/steps >> to follow, and therefore more error-prone. >> >> 6. The point about not being able to automate getting the latest stable MTT >> is a good one. How about using numerical tags just to delineate our >> intended "release" points, but also have a moveable tag, e.g., >> "ompi-mtt-testing" that will always point to the latest "release" that we >> want the OMPI MTT test community to use? That way, you can always "git >> checkout ompi-mtt-testing" to get the latest/greatest. >> >> (...to that end, I've created/pushed an ompi-mtt-testing tag and pointed to >> the same place as v3.0.0) >> >> >> >>> On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet >>> wrote: >>> >>> +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 >>> default) >>> - if you use the devel branch, one can only assume you know what you are >>>
Re: [MTT devel] MTT: let's use git tags
+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 default) - 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 Cheers, Gilles 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".
