oVirt packages for JavaScript development have been updated
Hello devs, following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated: * ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference. == 1, move your project from npm to Yarn: - using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this: ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1 - since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh == 2a, dependency handling - 1st time: - clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version 2b, dependency handling - whenever your dependencies change: - clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version == Q: how does the new nodejs-modules work? A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files. When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects. When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory. == Hope this helps. Regards, Vojtech
Vojtech, can you please help Ryan and Marek with cockpit-ovirt? On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
I can assist too. What do you need? If it's easier, I'm available on IRC. On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
On Fri, Feb 10, 2017 at 2:56 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
Hi guys, we can organize a short session to explain the changes and help people to use the new packages. Does that make sense? Generally, any project using nodejs-modules should move from npm to Yarn (using ovirt-engine-yarn) and then modify the `projects.list` file in nodejs-modules repo, see [1] for reference. [1] https://gerrit.ovirt.org/#/c/71134/ This triggers new nodejs-modules RPM build, which will contain all dependencies required by all projects defined via the the `projects.list` file. If you face issues with CI yum caching like we did in Dashboard (e.g. nodejs-modules defined in .packages file wasn't actually installed), you might try installing it manually in your build script, see [2] for reference. [2] https://gerrit.ovirt.org/#/c/71923/
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Nothing, but thanks. It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release). I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now. On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps. On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Thanks Greg! I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should. As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful. Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us. Any ideas? On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Hello devs,
following packages, intended as build-time dependencies of oVirt JavaScript projects, have been updated:
* ovirt-engine-nodejs * ovirt-engine-nodejs-modules * ovirt-engine-yarn
If you use those packages, please read on to learn how to adapt your project. oVirt Dashboard (master) is already adapted and you can use it as your reference.
==
1, move your project from npm to Yarn:
- using nodejs-modules implies that your project moves from npm to Yarn, please do this as your first step - make sure to add yarn.lock file to source control: rm -rf node_modules && yarn install # generates yarn.lock - your automation/*.packages should contain something like this:
ovirt-engine-nodejs-6.9.4 ovirt-engine-nodejs-modules-1.0.3 ovirt-engine-yarn-0.19.1
- since oVirt CI uses yum cache, always specify exact version of nodejs-modules in your automation/*.packages - in your RPM build script, make sure to set up Node.js env.: source /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
==
2a, dependency handling - 1st time:
- clone nodejs-modules repo & update the projects.list file - add URL(s) to your project's files (package.json + yarn.lock) - bump .z in RPM Version and reset the RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
2b, dependency handling - whenever your dependencies change:
- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit - in your project, update automation/*.packages to use the right nodejs-modules version
==
Q: how does the new nodejs-modules work?
A: instead of maintaining one big package.json file to specify all dependencies of all projects (effectively forcing all projects to use single dependency tree), it contains the projects.list file with URL(s) to specific project files.
When building nodejs-modules RPM, it goes through the list of URL(s), downloading project's files (package.json + yarn.lock), then downloading required dependencies (using Yarn) and collecting their .tar.gz sources. The nodejs-modules RPM therefore contains a flat list of all .tar.gz sources of all dependencies of all projects.
When you source the setup-env.sh script, it does, among other things, tell Yarn to use /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing all .tar.gz sources. Then, it runs Yarn in offline mode to populate your project's node_modules directory.
==
Hope this helps.
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it. I was next going to look into https://github.com/babel/grunt-babel/issues/56#issuecomment-154377457 and the comment after it. On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <sbonazzo@redhat.com
wrote:
Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
> Hello devs, > > following packages, intended as build-time dependencies of oVirt > JavaScript projects, have been updated: > > * ovirt-engine-nodejs > * ovirt-engine-nodejs-modules > * ovirt-engine-yarn > > If you use those packages, please read on to learn how to adapt your > project. oVirt Dashboard (master) is already adapted and you can use > it as your reference. > > == > > 1, move your project from npm to Yarn: > > - using nodejs-modules implies that your project moves from npm to > Yarn, please do this as your first step > - make sure to add yarn.lock file to source control: rm -rf > node_modules && yarn install # generates yarn.lock > - your automation/*.packages should contain something like this: > > ovirt-engine-nodejs-6.9.4 > ovirt-engine-nodejs-modules-1.0.3 > ovirt-engine-yarn-0.19.1 > > - since oVirt CI uses yum cache, always specify exact version of > nodejs-modules in your automation/*.packages > - in your RPM build script, make sure to set up Node.js env.: source > /usr/share/ovirt-engine-nodejs-modules/setup-env.sh > > == > > 2a, dependency handling - 1st time: > > - clone nodejs-modules repo & update the projects.list file - add > URL(s) to your project's files (package.json + yarn.lock) > - bump .z in RPM Version and reset the RPM Release number, submit > patch to Gerrit > - in your project, update automation/*.packages to use the right > nodejs-modules version > > 2b, dependency handling - whenever your dependencies change: > > - clone nodejs-modules repo & bump RPM Release number, submit patch > to Gerrit > - in your project, update automation/*.packages to use the right > nodejs-modules version > > == > > Q: how does the new nodejs-modules work? > > A: instead of maintaining one big package.json file to specify all > dependencies of all projects (effectively forcing all projects to use > single dependency tree), it contains the projects.list file with > URL(s) to specific project files. > > When building nodejs-modules RPM, it goes through the list of URL(s), > downloading project's files (package.json + yarn.lock), then > downloading required dependencies (using Yarn) and collecting their > .tar.gz sources. The nodejs-modules RPM therefore contains a flat > list > of all .tar.gz sources of all dependencies of all projects. > > When you source the setup-env.sh script, it does, among other things, > tell Yarn to use > /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing > all .tar.gz sources. Then, it runs Yarn in offline mode to populate > your project's node_modules directory. > > == > > Hope this helps. > > Regards, > Vojtech > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Ryan, try running webpack with --display-error-details parameter. Also, maybe this comment is related: https://github.com/webpack/webpack/issues/3242#issuecomment-260411104 AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably. Vojtech On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I can assist too. What do you need? If it's easier, I'm available on IRC.
On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < sbonazzo@redhat.com> wrote:
> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? > > > On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> > wrote: > >> Hello devs, >> >> following packages, intended as build-time dependencies of oVirt >> JavaScript projects, have been updated: >> >> * ovirt-engine-nodejs >> * ovirt-engine-nodejs-modules >> * ovirt-engine-yarn >> >> If you use those packages, please read on to learn how to adapt your >> project. oVirt Dashboard (master) is already adapted and you can use >> it as your reference. >> >> == >> >> 1, move your project from npm to Yarn: >> >> - using nodejs-modules implies that your project moves from npm to >> Yarn, please do this as your first step >> - make sure to add yarn.lock file to source control: rm -rf >> node_modules && yarn install # generates yarn.lock >> - your automation/*.packages should contain something like this: >> >> ovirt-engine-nodejs-6.9.4 >> ovirt-engine-nodejs-modules-1.0.3 >> ovirt-engine-yarn-0.19.1 >> >> - since oVirt CI uses yum cache, always specify exact version of >> nodejs-modules in your automation/*.packages >> - in your RPM build script, make sure to set up Node.js env.: source >> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >> >> == >> >> 2a, dependency handling - 1st time: >> >> - clone nodejs-modules repo & update the projects.list file - add >> URL(s) to your project's files (package.json + yarn.lock) >> - bump .z in RPM Version and reset the RPM Release number, submit >> patch to Gerrit >> - in your project, update automation/*.packages to use the right >> nodejs-modules version >> >> 2b, dependency handling - whenever your dependencies change: >> >> - clone nodejs-modules repo & bump RPM Release number, submit patch >> to Gerrit >> - in your project, update automation/*.packages to use the right >> nodejs-modules version >> >> == >> >> Q: how does the new nodejs-modules work? >> >> A: instead of maintaining one big package.json file to specify all >> dependencies of all projects (effectively forcing all projects to >> use >> single dependency tree), it contains the projects.list file with >> URL(s) to specific project files. >> >> When building nodejs-modules RPM, it goes through the list of >> URL(s), >> downloading project's files (package.json + yarn.lock), then >> downloading required dependencies (using Yarn) and collecting their >> .tar.gz sources. The nodejs-modules RPM therefore contains a flat >> list >> of all .tar.gz sources of all dependencies of all projects. >> >> When you source the setup-env.sh script, it does, among other >> things, >> tell Yarn to use >> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >> containing >> all .tar.gz sources. Then, it runs Yarn in offline mode to populate >> your project's node_modules directory. >> >> == >> >> Hope this helps. >> >> Regards, >> Vojtech >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community > collaboration. > See how it works at redhat.com > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Ryan, I was curious, had to try it myself :) Vojtech's suggestion of bumping up all your dependencies does the trick. Patch attached (there were some quirks -- hopefully this helps) Greg On Fri, Feb 10, 2017 at 12:10 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Ryan, try running webpack with --display-error-details parameter.
Also, maybe this comment is related: https://github.com/webpack/ webpack/issues/3242#issuecomment-260411104
AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably.
Vojtech
On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
Nothing, but thanks.
It is/was a question of time. I didn't expect the changes to ovirt-engine-modules to make it into master as quickly as they did (to be fair, it's been nearly a month since the initial meeting, but that month passed very quickly prepping for the beta release).
I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again now.
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
> I can assist too. What do you need? If it's easier, I'm available on > IRC. > > On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < > sbonazzo@redhat.com> wrote: > >> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? >> >> >> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> >> wrote: >> >>> Hello devs, >>> >>> following packages, intended as build-time dependencies of oVirt >>> JavaScript projects, have been updated: >>> >>> * ovirt-engine-nodejs >>> * ovirt-engine-nodejs-modules >>> * ovirt-engine-yarn >>> >>> If you use those packages, please read on to learn how to adapt >>> your >>> project. oVirt Dashboard (master) is already adapted and you can >>> use >>> it as your reference. >>> >>> == >>> >>> 1, move your project from npm to Yarn: >>> >>> - using nodejs-modules implies that your project moves from npm to >>> Yarn, please do this as your first step >>> - make sure to add yarn.lock file to source control: rm -rf >>> node_modules && yarn install # generates yarn.lock >>> - your automation/*.packages should contain something like this: >>> >>> ovirt-engine-nodejs-6.9.4 >>> ovirt-engine-nodejs-modules-1.0.3 >>> ovirt-engine-yarn-0.19.1 >>> >>> - since oVirt CI uses yum cache, always specify exact version of >>> nodejs-modules in your automation/*.packages >>> - in your RPM build script, make sure to set up Node.js env.: >>> source >>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >>> >>> == >>> >>> 2a, dependency handling - 1st time: >>> >>> - clone nodejs-modules repo & update the projects.list file - add >>> URL(s) to your project's files (package.json + yarn.lock) >>> - bump .z in RPM Version and reset the RPM Release number, submit >>> patch to Gerrit >>> - in your project, update automation/*.packages to use the right >>> nodejs-modules version >>> >>> 2b, dependency handling - whenever your dependencies change: >>> >>> - clone nodejs-modules repo & bump RPM Release number, submit >>> patch to Gerrit >>> - in your project, update automation/*.packages to use the right >>> nodejs-modules version >>> >>> == >>> >>> Q: how does the new nodejs-modules work? >>> >>> A: instead of maintaining one big package.json file to specify all >>> dependencies of all projects (effectively forcing all projects to >>> use >>> single dependency tree), it contains the projects.list file with >>> URL(s) to specific project files. >>> >>> When building nodejs-modules RPM, it goes through the list of >>> URL(s), >>> downloading project's files (package.json + yarn.lock), then >>> downloading required dependencies (using Yarn) and collecting their >>> .tar.gz sources. The nodejs-modules RPM therefore contains a flat >>> list >>> of all .tar.gz sources of all dependencies of all projects. >>> >>> When you source the setup-env.sh script, it does, among other >>> things, >>> tell Yarn to use >>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >>> containing >>> all .tar.gz sources. Then, it runs Yarn in offline mode to populate >>> your project's node_modules directory. >>> >>> == >>> >>> Hope this helps. >>> >>> Regards, >>> Vojtech >>> _______________________________________________ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community >> collaboration. >> See how it works at redhat.com >> >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gshereme@redhat.com >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Awesome, thanks guys! On Feb 10, 2017 11:43, "Greg Sheremeta" <gshereme@redhat.com> wrote:
Ryan,
I was curious, had to try it myself :) Vojtech's suggestion of bumping up all your dependencies does the trick. Patch attached (there were some quirks -- hopefully this helps)
Greg
On Fri, Feb 10, 2017 at 12:10 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Ryan, try running webpack with --display-error-details parameter.
Also, maybe this comment is related: https://github.com/webpack/web pack/issues/3242#issuecomment-260411104
AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably.
Vojtech
On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> wrote:
> Nothing, but thanks. > > It is/was a question of time. I didn't expect the changes to > ovirt-engine-modules to make it into master as quickly as they did (to be > fair, it's been nearly a month since the initial meeting, but that month > passed very quickly prepping for the beta release). > > I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules > to get cockpit-ovirt working on master again now. >
Please add Greg & me as reviewers :-) also, if there are any open issues or questions, let us know.
> > On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta <gshereme@redhat.com > > wrote: > >> I can assist too. What do you need? If it's easier, I'm available >> on IRC. >> >> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < >> sbonazzo@redhat.com> wrote: >> >>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? >>> >>> >>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> >>> wrote: >>> >>>> Hello devs, >>>> >>>> following packages, intended as build-time dependencies of oVirt >>>> JavaScript projects, have been updated: >>>> >>>> * ovirt-engine-nodejs >>>> * ovirt-engine-nodejs-modules >>>> * ovirt-engine-yarn >>>> >>>> If you use those packages, please read on to learn how to adapt >>>> your >>>> project. oVirt Dashboard (master) is already adapted and you can >>>> use >>>> it as your reference. >>>> >>>> == >>>> >>>> 1, move your project from npm to Yarn: >>>> >>>> - using nodejs-modules implies that your project moves from npm to >>>> Yarn, please do this as your first step >>>> - make sure to add yarn.lock file to source control: rm -rf >>>> node_modules && yarn install # generates yarn.lock >>>> - your automation/*.packages should contain something like this: >>>> >>>> ovirt-engine-nodejs-6.9.4 >>>> ovirt-engine-nodejs-modules-1.0.3 >>>> ovirt-engine-yarn-0.19.1 >>>> >>>> - since oVirt CI uses yum cache, always specify exact version of >>>> nodejs-modules in your automation/*.packages >>>> - in your RPM build script, make sure to set up Node.js env.: >>>> source >>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >>>> >>>> == >>>> >>>> 2a, dependency handling - 1st time: >>>> >>>> - clone nodejs-modules repo & update the projects.list file - add >>>> URL(s) to your project's files (package.json + yarn.lock) >>>> - bump .z in RPM Version and reset the RPM Release number, submit >>>> patch to Gerrit >>>> - in your project, update automation/*.packages to use the right >>>> nodejs-modules version >>>> >>>> 2b, dependency handling - whenever your dependencies change: >>>> >>>> - clone nodejs-modules repo & bump RPM Release number, submit >>>> patch to Gerrit >>>> - in your project, update automation/*.packages to use the right >>>> nodejs-modules version >>>> >>>> == >>>> >>>> Q: how does the new nodejs-modules work? >>>> >>>> A: instead of maintaining one big package.json file to specify all >>>> dependencies of all projects (effectively forcing all projects to >>>> use >>>> single dependency tree), it contains the projects.list file with >>>> URL(s) to specific project files. >>>> >>>> When building nodejs-modules RPM, it goes through the list of >>>> URL(s), >>>> downloading project's files (package.json + yarn.lock), then >>>> downloading required dependencies (using Yarn) and collecting >>>> their >>>> .tar.gz sources. The nodejs-modules RPM therefore contains a flat >>>> list >>>> of all .tar.gz sources of all dependencies of all projects. >>>> >>>> When you source the setup-env.sh script, it does, among other >>>> things, >>>> tell Yarn to use >>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >>>> containing >>>> all .tar.gz sources. Then, it runs Yarn in offline mode to >>>> populate >>>> your project's node_modules directory. >>>> >>>> == >>>> >>>> Hope this helps. >>>> >>>> Regards, >>>> Vojtech >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> >>> >>> >>> -- >>> Sandro Bonazzola >>> Better technology. Faster innovation. Powered by community >>> collaboration. >>> See how it works at redhat.com >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> >> -- >> Greg Sheremeta, MBA >> Red Hat, Inc. >> Sr. Software Engineer >> gshereme@redhat.com >> > >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Just so nobody repeats my mistake -- In 2b (from the original email) -- if dependencies are updated, you must also: - Resynchronize the yarn.lock in your project file if you bump dependencies versions, otherwise yarn.lock will not agree with package.json, and your build will fail... On Fri, Feb 10, 2017 at 11:44 AM, Ryan Barry <rbarry@redhat.com> wrote:
Awesome, thanks guys!
On Feb 10, 2017 11:43, "Greg Sheremeta" <gshereme@redhat.com> wrote:
Ryan,
I was curious, had to try it myself :) Vojtech's suggestion of bumping up all your dependencies does the trick. Patch attached (there were some quirks -- hopefully this helps)
Greg
On Fri, Feb 10, 2017 at 12:10 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Ryan, try running webpack with --display-error-details parameter.
Also, maybe this comment is related: https://github.com/webpack/web pack/issues/3242#issuecomment-260411104
AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably.
Vojtech
On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
I didn't realize Ryan was already doing this, so here was my take (attached). Maybe it helps.
On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
> > > On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> > wrote: > >> Nothing, but thanks. >> >> It is/was a question of time. I didn't expect the changes to >> ovirt-engine-modules to make it into master as quickly as they did (to be >> fair, it's been nearly a month since the initial meeting, but that month >> passed very quickly prepping for the beta release). >> >> I'm pushing patches to cockpit-ovirt and >> ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again >> now. >> > > Please add Greg & me as reviewers :-) also, if there are any open > issues or questions, let us know. > > >> >> On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta < >> gshereme@redhat.com> wrote: >> >>> I can assist too. What do you need? If it's easier, I'm available >>> on IRC. >>> >>> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < >>> sbonazzo@redhat.com> wrote: >>> >>>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? >>>> >>>> >>>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com> >>>> wrote: >>>> >>>>> Hello devs, >>>>> >>>>> following packages, intended as build-time dependencies of oVirt >>>>> JavaScript projects, have been updated: >>>>> >>>>> * ovirt-engine-nodejs >>>>> * ovirt-engine-nodejs-modules >>>>> * ovirt-engine-yarn >>>>> >>>>> If you use those packages, please read on to learn how to adapt >>>>> your >>>>> project. oVirt Dashboard (master) is already adapted and you can >>>>> use >>>>> it as your reference. >>>>> >>>>> == >>>>> >>>>> 1, move your project from npm to Yarn: >>>>> >>>>> - using nodejs-modules implies that your project moves from npm >>>>> to >>>>> Yarn, please do this as your first step >>>>> - make sure to add yarn.lock file to source control: rm -rf >>>>> node_modules && yarn install # generates yarn.lock >>>>> - your automation/*.packages should contain something like this: >>>>> >>>>> ovirt-engine-nodejs-6.9.4 >>>>> ovirt-engine-nodejs-modules-1.0.3 >>>>> ovirt-engine-yarn-0.19.1 >>>>> >>>>> - since oVirt CI uses yum cache, always specify exact version of >>>>> nodejs-modules in your automation/*.packages >>>>> - in your RPM build script, make sure to set up Node.js env.: >>>>> source >>>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >>>>> >>>>> == >>>>> >>>>> 2a, dependency handling - 1st time: >>>>> >>>>> - clone nodejs-modules repo & update the projects.list file - add >>>>> URL(s) to your project's files (package.json + yarn.lock) >>>>> - bump .z in RPM Version and reset the RPM Release number, submit >>>>> patch to Gerrit >>>>> - in your project, update automation/*.packages to use the right >>>>> nodejs-modules version >>>>> >>>>> 2b, dependency handling - whenever your dependencies change: >>>>> >>>>> - clone nodejs-modules repo & bump RPM Release number, submit >>>>> patch to Gerrit >>>>> - in your project, update automation/*.packages to use the right >>>>> nodejs-modules version >>>>> >>>>> == >>>>> >>>>> Q: how does the new nodejs-modules work? >>>>> >>>>> A: instead of maintaining one big package.json file to specify >>>>> all >>>>> dependencies of all projects (effectively forcing all projects >>>>> to use >>>>> single dependency tree), it contains the projects.list file with >>>>> URL(s) to specific project files. >>>>> >>>>> When building nodejs-modules RPM, it goes through the list of >>>>> URL(s), >>>>> downloading project's files (package.json + yarn.lock), then >>>>> downloading required dependencies (using Yarn) and collecting >>>>> their >>>>> .tar.gz sources. The nodejs-modules RPM therefore contains a >>>>> flat list >>>>> of all .tar.gz sources of all dependencies of all projects. >>>>> >>>>> When you source the setup-env.sh script, it does, among other >>>>> things, >>>>> tell Yarn to use >>>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >>>>> containing >>>>> all .tar.gz sources. Then, it runs Yarn in offline mode to >>>>> populate >>>>> your project's node_modules directory. >>>>> >>>>> == >>>>> >>>>> Hope this helps. >>>>> >>>>> Regards, >>>>> Vojtech >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>> >>>> >>>> >>>> -- >>>> Sandro Bonazzola >>>> Better technology. Faster innovation. Powered by community >>>> collaboration. >>>> See how it works at redhat.com >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> >>> >>> >>> -- >>> Greg Sheremeta, MBA >>> Red Hat, Inc. >>> Sr. Software Engineer >>> gshereme@redhat.com >>> >> >> >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
Build of ovirt-engine-nodejs-modules is failing on missing history-4.5.1. requested by cockpit-ovirt/dashboad/package.json . This dependency was introduced in the patch sent in one of the previous emails in this thread. Please have a look at https://gerrit.ovirt.org/#/c/72508 . The history-4.5.1 can be installed via npm. Dependencies for other projects listed in the projects.list can be resolved. On Thu, Feb 16, 2017 at 5:48 PM, Ryan Barry <rbarry@redhat.com> wrote:
Just so nobody repeats my mistake --
In 2b (from the original email) -- if dependencies are updated, you must also:
- Resynchronize the yarn.lock in your project file if you bump dependencies versions, otherwise yarn.lock will not agree with package.json, and your build will fail...
On Fri, Feb 10, 2017 at 11:44 AM, Ryan Barry <rbarry@redhat.com> wrote:
Awesome, thanks guys!
On Feb 10, 2017 11:43, "Greg Sheremeta" <gshereme@redhat.com> wrote:
Ryan,
I was curious, had to try it myself :) Vojtech's suggestion of bumping up all your dependencies does the trick. Patch attached (there were some quirks -- hopefully this helps)
Greg
On Fri, Feb 10, 2017 at 12:10 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Ryan, try running webpack with --display-error-details parameter.
Also, maybe this comment is related: https://github.com/webpack/web pack/issues/3242#issuecomment-260411104
AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably.
Vojtech
On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
Thanks Greg!
I actually merged patches for it to work, but it's always nice to see another approach, and in looking at your diff, I see that I also didn't change "--with-npm-install", which I should.
As long as we have you on the phone (so to speak), I'm actually curious about ovirt-engine-nodejs. We've been having failures in CI since December, give or take, but they're not tied to any particular patch. That is to say that checking out an earlier commit still suddenly fails. This has been a low-grade annoyance while we prep for 4.1, since everything still builds and runs in build-artifacts without any problems, but getitng "-1 Continuous Integration" on every patch isn't very helpful.
Webpack complains "PATH should be a string, is undefined", but never tells me where it's looking for this. We don't use path.resolve anywhere and I've probably tried every suggestion on github/stackoverflow for making this go away, without any success. There are a lot of reports that changing the downgrading the NodeJS major version (from 6 -> 5, generally) resolves this,b ut that's obviously not an option for us.
Any ideas?
On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com> wrote:
> I didn't realize Ryan was already doing this, so here was my take > (attached). Maybe it helps. > > > > On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> > wrote: > >> >> >> On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> >> wrote: >> >>> Nothing, but thanks. >>> >>> It is/was a question of time. I didn't expect the changes to >>> ovirt-engine-modules to make it into master as quickly as they did (to be >>> fair, it's been nearly a month since the initial meeting, but that month >>> passed very quickly prepping for the beta release). >>> >>> I'm pushing patches to cockpit-ovirt and >>> ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again >>> now. >>> >> >> Please add Greg & me as reviewers :-) also, if there are any open >> issues or questions, let us know. >> >> >>> >>> On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta < >>> gshereme@redhat.com> wrote: >>> >>>> I can assist too. What do you need? If it's easier, I'm available >>>> on IRC. >>>> >>>> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < >>>> sbonazzo@redhat.com> wrote: >>>> >>>>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? >>>>> >>>>> >>>>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs <vszocs@redhat.com >>>>> > wrote: >>>>> >>>>>> Hello devs, >>>>>> >>>>>> following packages, intended as build-time dependencies of oVirt >>>>>> JavaScript projects, have been updated: >>>>>> >>>>>> * ovirt-engine-nodejs >>>>>> * ovirt-engine-nodejs-modules >>>>>> * ovirt-engine-yarn >>>>>> >>>>>> If you use those packages, please read on to learn how to adapt >>>>>> your >>>>>> project. oVirt Dashboard (master) is already adapted and you >>>>>> can use >>>>>> it as your reference. >>>>>> >>>>>> == >>>>>> >>>>>> 1, move your project from npm to Yarn: >>>>>> >>>>>> - using nodejs-modules implies that your project moves from npm >>>>>> to >>>>>> Yarn, please do this as your first step >>>>>> - make sure to add yarn.lock file to source control: rm -rf >>>>>> node_modules && yarn install # generates yarn.lock >>>>>> - your automation/*.packages should contain something like this: >>>>>> >>>>>> ovirt-engine-nodejs-6.9.4 >>>>>> ovirt-engine-nodejs-modules-1.0.3 >>>>>> ovirt-engine-yarn-0.19.1 >>>>>> >>>>>> - since oVirt CI uses yum cache, always specify exact version of >>>>>> nodejs-modules in your automation/*.packages >>>>>> - in your RPM build script, make sure to set up Node.js env.: >>>>>> source >>>>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >>>>>> >>>>>> == >>>>>> >>>>>> 2a, dependency handling - 1st time: >>>>>> >>>>>> - clone nodejs-modules repo & update the projects.list file - >>>>>> add >>>>>> URL(s) to your project's files (package.json + yarn.lock) >>>>>> - bump .z in RPM Version and reset the RPM Release number, >>>>>> submit >>>>>> patch to Gerrit >>>>>> - in your project, update automation/*.packages to use the right >>>>>> nodejs-modules version >>>>>> >>>>>> 2b, dependency handling - whenever your dependencies change: >>>>>> >>>>>> - clone nodejs-modules repo & bump RPM Release number, submit >>>>>> patch to Gerrit >>>>>> - in your project, update automation/*.packages to use the right >>>>>> nodejs-modules version >>>>>> >>>>>> == >>>>>> >>>>>> Q: how does the new nodejs-modules work? >>>>>> >>>>>> A: instead of maintaining one big package.json file to specify >>>>>> all >>>>>> dependencies of all projects (effectively forcing all projects >>>>>> to use >>>>>> single dependency tree), it contains the projects.list file with >>>>>> URL(s) to specific project files. >>>>>> >>>>>> When building nodejs-modules RPM, it goes through the list of >>>>>> URL(s), >>>>>> downloading project's files (package.json + yarn.lock), then >>>>>> downloading required dependencies (using Yarn) and collecting >>>>>> their >>>>>> .tar.gz sources. The nodejs-modules RPM therefore contains a >>>>>> flat list >>>>>> of all .tar.gz sources of all dependencies of all projects. >>>>>> >>>>>> When you source the setup-env.sh script, it does, among other >>>>>> things, >>>>>> tell Yarn to use >>>>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >>>>>> containing >>>>>> all .tar.gz sources. Then, it runs Yarn in offline mode to >>>>>> populate >>>>>> your project's node_modules directory. >>>>>> >>>>>> == >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> Regards, >>>>>> Vojtech >>>>>> _______________________________________________ >>>>>> Devel mailing list >>>>>> Devel@ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sandro Bonazzola >>>>> Better technology. Faster innovation. Powered by community >>>>> collaboration. >>>>> See how it works at redhat.com >>>>> >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>> >>>> >>>> >>>> -- >>>> Greg Sheremeta, MBA >>>> Red Hat, Inc. >>>> Sr. Software Engineer >>>> gshereme@redhat.com >>>> >>> >>> >> > > > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gshereme@redhat.com >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
We figured this out -- when Ryan updated the lock file two messages ago, he was in yarn offline mode. Projects must have lock files with the URLs in them (online-style). Action item for me is to add a check in nodejs-modules for incoming offline-style lockfiles, and fail the build if found. Best wishes, Greg On Fri, Feb 17, 2017 at 8:35 AM, Marek Libra <mlibra@redhat.com> wrote:
Build of ovirt-engine-nodejs-modules is failing on missing history-4.5.1. requested by cockpit-ovirt/dashboad/package.json . This dependency was introduced in the patch sent in one of the previous emails in this thread. Please have a look at https://gerrit.ovirt.org/#/c/72508 .
The history-4.5.1 can be installed via npm.
Dependencies for other projects listed in the projects.list can be resolved.
On Thu, Feb 16, 2017 at 5:48 PM, Ryan Barry <rbarry@redhat.com> wrote:
Just so nobody repeats my mistake --
In 2b (from the original email) -- if dependencies are updated, you must also:
- Resynchronize the yarn.lock in your project file if you bump dependencies versions, otherwise yarn.lock will not agree with package.json, and your build will fail...
On Fri, Feb 10, 2017 at 11:44 AM, Ryan Barry <rbarry@redhat.com> wrote:
Awesome, thanks guys!
On Feb 10, 2017 11:43, "Greg Sheremeta" <gshereme@redhat.com> wrote:
Ryan,
I was curious, had to try it myself :) Vojtech's suggestion of bumping up all your dependencies does the trick. Patch attached (there were some quirks -- hopefully this helps)
Greg
On Fri, Feb 10, 2017 at 12:10 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Ryan, try running webpack with --display-error-details parameter.
Also, maybe this comment is related: https://github.com/webpack/web pack/issues/3242#issuecomment-260411104
AFAIK, Node.js v6 path APIs had some changes, which possibly broke some webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack plugin authors to fix their issues, you'll need to bump some versions in package.json probably.
Vojtech
On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
I'm clueless. Lol, actually I was just debugging the exact same thing when I saw your email that you were working on it.
I was next going to look into https://github.com/babel/ grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry <rbarry@redhat.com> wrote:
> Thanks Greg! > > I actually merged patches for it to work, but it's always nice to > see another approach, and in looking at your diff, I see that I also didn't > change "--with-npm-install", which I should. > > As long as we have you on the phone (so to speak), I'm actually > curious about ovirt-engine-nodejs. We've been having failures in CI since > December, give or take, but they're not tied to any particular patch. That > is to say that checking out an earlier commit still suddenly fails. This > has been a low-grade annoyance while we prep for 4.1, since everything > still builds and runs in build-artifacts without any problems, but getitng > "-1 Continuous Integration" on every patch isn't very helpful. > > Webpack complains "PATH should be a string, is undefined", but never > tells me where it's looking for this. We don't use path.resolve anywhere > and I've probably tried every suggestion on github/stackoverflow for making > this go away, without any success. There are a lot of reports that changing > the downgrading the NodeJS major version (from 6 -> 5, generally) resolves > this,b ut that's obviously not an option for us. > > Any ideas? > > On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta <gshereme@redhat.com > > wrote: > >> I didn't realize Ryan was already doing this, so here was my take >> (attached). Maybe it helps. >> >> >> >> On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs <vszocs@redhat.com> >> wrote: >> >>> >>> >>> On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry <rbarry@redhat.com> >>> wrote: >>> >>>> Nothing, but thanks. >>>> >>>> It is/was a question of time. I didn't expect the changes to >>>> ovirt-engine-modules to make it into master as quickly as they did (to be >>>> fair, it's been nearly a month since the initial meeting, but that month >>>> passed very quickly prepping for the beta release). >>>> >>>> I'm pushing patches to cockpit-ovirt and >>>> ovirt-engine-nodejs-modules to get cockpit-ovirt working on master again >>>> now. >>>> >>> >>> Please add Greg & me as reviewers :-) also, if there are any open >>> issues or questions, let us know. >>> >>> >>>> >>>> On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta < >>>> gshereme@redhat.com> wrote: >>>> >>>>> I can assist too. What do you need? If it's easier, I'm >>>>> available on IRC. >>>>> >>>>> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola < >>>>> sbonazzo@redhat.com> wrote: >>>>> >>>>>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt? >>>>>> >>>>>> >>>>>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs < >>>>>> vszocs@redhat.com> wrote: >>>>>> >>>>>>> Hello devs, >>>>>>> >>>>>>> following packages, intended as build-time dependencies of >>>>>>> oVirt >>>>>>> JavaScript projects, have been updated: >>>>>>> >>>>>>> * ovirt-engine-nodejs >>>>>>> * ovirt-engine-nodejs-modules >>>>>>> * ovirt-engine-yarn >>>>>>> >>>>>>> If you use those packages, please read on to learn how to >>>>>>> adapt your >>>>>>> project. oVirt Dashboard (master) is already adapted and you >>>>>>> can use >>>>>>> it as your reference. >>>>>>> >>>>>>> == >>>>>>> >>>>>>> 1, move your project from npm to Yarn: >>>>>>> >>>>>>> - using nodejs-modules implies that your project moves from >>>>>>> npm to >>>>>>> Yarn, please do this as your first step >>>>>>> - make sure to add yarn.lock file to source control: rm -rf >>>>>>> node_modules && yarn install # generates yarn.lock >>>>>>> - your automation/*.packages should contain something like >>>>>>> this: >>>>>>> >>>>>>> ovirt-engine-nodejs-6.9.4 >>>>>>> ovirt-engine-nodejs-modules-1.0.3 >>>>>>> ovirt-engine-yarn-0.19.1 >>>>>>> >>>>>>> - since oVirt CI uses yum cache, always specify exact version >>>>>>> of >>>>>>> nodejs-modules in your automation/*.packages >>>>>>> - in your RPM build script, make sure to set up Node.js env.: >>>>>>> source >>>>>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh >>>>>>> >>>>>>> == >>>>>>> >>>>>>> 2a, dependency handling - 1st time: >>>>>>> >>>>>>> - clone nodejs-modules repo & update the projects.list file - >>>>>>> add >>>>>>> URL(s) to your project's files (package.json + yarn.lock) >>>>>>> - bump .z in RPM Version and reset the RPM Release number, >>>>>>> submit >>>>>>> patch to Gerrit >>>>>>> - in your project, update automation/*.packages to use the >>>>>>> right >>>>>>> nodejs-modules version >>>>>>> >>>>>>> 2b, dependency handling - whenever your dependencies change: >>>>>>> >>>>>>> - clone nodejs-modules repo & bump RPM Release number, submit >>>>>>> patch to Gerrit >>>>>>> - in your project, update automation/*.packages to use the >>>>>>> right >>>>>>> nodejs-modules version >>>>>>> >>>>>>> == >>>>>>> >>>>>>> Q: how does the new nodejs-modules work? >>>>>>> >>>>>>> A: instead of maintaining one big package.json file to specify >>>>>>> all >>>>>>> dependencies of all projects (effectively forcing all projects >>>>>>> to use >>>>>>> single dependency tree), it contains the projects.list file >>>>>>> with >>>>>>> URL(s) to specific project files. >>>>>>> >>>>>>> When building nodejs-modules RPM, it goes through the list of >>>>>>> URL(s), >>>>>>> downloading project's files (package.json + yarn.lock), then >>>>>>> downloading required dependencies (using Yarn) and collecting >>>>>>> their >>>>>>> .tar.gz sources. The nodejs-modules RPM therefore contains a >>>>>>> flat list >>>>>>> of all .tar.gz sources of all dependencies of all projects. >>>>>>> >>>>>>> When you source the setup-env.sh script, it does, among other >>>>>>> things, >>>>>>> tell Yarn to use >>>>>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache >>>>>>> containing >>>>>>> all .tar.gz sources. Then, it runs Yarn in offline mode to >>>>>>> populate >>>>>>> your project's node_modules directory. >>>>>>> >>>>>>> == >>>>>>> >>>>>>> Hope this helps. >>>>>>> >>>>>>> Regards, >>>>>>> Vojtech >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel@ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sandro Bonazzola >>>>>> Better technology. Faster innovation. Powered by community >>>>>> collaboration. >>>>>> See how it works at redhat.com >>>>>> >>>>>> _______________________________________________ >>>>>> Devel mailing list >>>>>> Devel@ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Greg Sheremeta, MBA >>>>> Red Hat, Inc. >>>>> Sr. Software Engineer >>>>> gshereme@redhat.com >>>>> >>>> >>>> >>> >> >> >> -- >> Greg Sheremeta, MBA >> Red Hat, Inc. >> Sr. Software Engineer >> gshereme@redhat.com >> > >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
participants (5)
-
Greg Sheremeta -
Marek Libra -
Ryan Barry -
Sandro Bonazzola -
Vojtech Szocs