- 10 Apr, 2018 1 commit
-
-
Alain Takoudjou authored
-
- 07 Apr, 2018 1 commit
-
-
Julien Muchembled authored
-
- 06 Apr, 2018 1 commit
-
-
Julien Muchembled authored
-
- 05 Apr, 2018 1 commit
-
-
Julien Muchembled authored
-
- 04 Apr, 2018 6 commits
-
-
Julien Muchembled authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
Instead of having running test installing eggs with setuptools during `python setup.py test`, which fails for `caucase` because one of its dependency (namely `cryptography`) cannot be installed so easily, we want to install the dependencies via buildout, using the same installation methods than in the actual software profiles using our eggs. What I initially believed would be a small change turned out to be a long journey, especially because of using a develop version of `slapos.recipe.cmmi` caused signature changes in the parts installed by this recipe ( `git`, `openssl` etc - some parts that takes a bit of time to install ) so I had to fight with the software being reinstalled each time. Even though the cases which leads to reinstallation are understood (this even involved fixing a bug in buildout nexedi/slapos.buildout!14 ), this is still the case. Some solutions are proposed in the commit message of f4b6eedafd52b0d64f8b2bd1b57c752e02c88a65 , but this reached a state where we can consider first merging with this known problem or discuss ways of improving that before merging if it's considered as blocking. Current state is that it takes one hour to re-install what has to be reinstalled and run the test suite on test runner. Despite this issue, this approach already improve things, because: * `caucase` tests are running (and passing) * some `slapos.cookbook` are improved so that they reuse eggs from the buildout and do not install again eggs when the are run. * ... and some other small cleanups This depends on nexedi/erp5!619 on the `erp5.util` side. /reviewed-on nexedi/slapos!309
-
Jérome Perrin authored
This function factorize the code to instanciate a recipe in a fake buildout. The new feature is that if running in a buildout directory, the recipe will reuse the eggs from this buildout instead of trying to install eggs again.
-
Jérome Perrin authored
we now use slapos.cookbook:wrapper instead
-
Jérome Perrin authored
Instead of letting `python setup.py test` install the depencies, use buildout way of installing the eggs. This software use `interpreter` recipe of `zc.recipe.egg` to install a python with all eggs pre-installed. This is a way to get all the dependencies at install time instead of getting them at run time from pypi when running `python setup.py test`. `erp5.util.testsuite` has been extended to support a parameter to specify which python interpreter to use. One issue is that this way of installing eggs by buildout cause chicken and egg problem: cloning repository containing `slapos.recipe.cmmi` needs git, and to compiling git needs `slapos.recipe.cmmi`. The consequence of this is that re-running software will install too many parts again. One solution for this would be to clone `slapos.recipe.cmmi` with a `git` command provided by testnode or system package. Another solution would be to not install `slapos.recipe.cmmi` develop egg, simply install the egg from it's current pypi version while installing the software (running tests will be from the git checkout anyway). For now this is open issue. Another point of attention is that `python setup.py test` install the requirements listed in `test_requires`, but `zc.recipe.egg` does not provide a way of installing these. Some of our packages have `[test]` entrypoints, in this case, the software installs the test entrypoints. For others, we install the eggs. Other improvements: * use a simple `slapos.recipe:wrapper` instead of `slapos.cookbook:egg_test` * fix the typo in repository name erp5-util-repository -> erp5.util-repository ( this mean we will have to fix the test suites in nexedi ERP5 ) * document "what is this software" and a scenario of how this software can be used to develop slapos eggs. * switch to buildout-hash.cfg for easier template hash management.
-
- 30 Mar, 2018 3 commits
-
-
Alain Takoudjou authored
-
Alain Takoudjou authored
-
Alain Takoudjou authored
-
- 29 Mar, 2018 6 commits
-
-
Alain Takoudjou authored
/reviewed-on nexedi/slapos!308
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Rafael Monnerat authored
-
- 28 Mar, 2018 2 commits
-
-
Alain Takoudjou authored
-
-
- 27 Mar, 2018 6 commits
-
-
Alain Takoudjou authored
-
Alain Takoudjou authored
monitor: move scripts wrapper and logrotate conf to buildout, uses some new promises from slapos.toolbox monitor was updated in slapos.toolbox to not generate promise launcher scripts anymore. All generated scripts are now in buildout. Monitor promise run script is removed from cron, slapgrid is used to run promises. Replace some old promises by the new ones from slapos.toolbox. Cleanup monitor configuration. Monitor report and monitor-promises directory are now obsolete.
-
Alain Takoudjou authored
-
Kazuhiko Shiozaki authored
-
Julien Muchembled authored
-
Kirill Smelkov authored
Update verion of lab.nexed.com/kirr/neo.git used and all of its dependencies. NEO/go now uses 2 Cgo packages: - github.com/gwenn/gosqlite, and - github.com/DataDog/czlib and github.com/soheilhy/cmux to multiplex NEO & HTTP traffic on the same port. Otherwise it is straighforward update which transitively pulled some more dependencies.
-
- 26 Mar, 2018 2 commits
-
-
Kirill Smelkov authored
The most convenient way to discover CFLAGS/LDFLAGS when building Cgo bits is via pkg-config: https://golang.org/cmd/cgo/ For this to work let's add pkg-config to be available there in gowork out of the box, and provide users with a way to specify which C packages they want to be there on gowork's $PKG_CONFIG_PATH, e.g. this way: [gowork] cpkgpath = ${sqlite3:location}/lib/pkgconfig ${zlib:location}/lib/pkgconfig In buildout sources cpkgpath is specified as multiline - not one line with ":" delimiters - with the idea that it should be easy to amend gowork.cpkgpath with "+=" in different places.
-
Alain Takoudjou authored
-
- 25 Mar, 2018 1 commit
-
-
Kirill Smelkov authored
Upgrading passes python-2.7 compile and tests. Let's hope it will be ok everywhere else.
-
- 22 Mar, 2018 1 commit
-
-
Rafael Monnerat authored
-
- 21 Mar, 2018 3 commits
-
-
Boris Kocherov authored
Hello @alain.takoudjou could you please try to build this branch. /reviewed-on nexedi/slapos!305
-
Boris Kocherov authored
-
Julien Muchembled authored
-
- 20 Mar, 2018 2 commits
-
-
Boris Kocherov authored
-
Jérome Perrin authored
Rewriting commit history with `git rebase -i` always caused some conflicts on md5sum of modified files. `update-hash` made all this easier, because we could just revert buildout.hash.cfg, re-run `update-hash` and commit the changes. This tool makes this scenario a bit more user friendly by automating the steps by running as a git mergetool. An interactive rebase session can be initiated by running this command from software/*/ directory: `git rebase -i --exec "$(pwd)/../../update-hash $(pwd)/buildout.hash.cfg" origin/master` and if conflict occur, run: `git mergetool --tool update-hash-mergetool && EDITOR=cat git rebase --continue` This way, rebase session can be almost non interactive (still have to run the above mergetool command) when conflicts are only on md5sum updates. /reviewed-on !273
-
- 19 Mar, 2018 3 commits
-
-
Romain Courteaud authored
-
Rafael Monnerat authored
This might be refactored in short future with caucase, however for now this change is required to slapos master works.
-
- 16 Mar, 2018 1 commit
-
-
Julien Muchembled authored
-