CI with Travis CI

Hello, it's me again :)
Unfortunately, for some reason ./vendor/bin/simple-phpunit install didn't work as expected. I see the message: <i>No such file or directory (errno 2) in /home/travis/build/BooleanType/symfony_knpu_lorem_ipsum_bundle/vendor/symfony/phpunit-bridge/bin/simple-phpunit.php</i>. This introduces other errors related to the package. I can't figure it out, 'cause I have no experience with Travis CI and similar tools.

Here is my problem build (it exited with 0, but without tests. symfony/phpunit-bridge has been though installed): https://travis-ci.com/github/BooleanType/symfony_knpu_lorem_ipsum_bundle/jobs/486041211

And here is my simplified travis.yml:

language: php
sudo: false
cache:
    directories:
        - $HOME/.composer/cache/files
        - $HOME/symfony-bridge/.phpunit

env:
    global:
        - PHPUNIT_FLAGS="-v"
        - SYMFONY_PHPUNIT_DIR="$HOME/symfony-bridge/.phpunit"

matrix:
    fast_finish: true
    include:
          # Minimum supported dependencies with the latest and oldest PHP version       
        - php: 7.4
          env: COMPOSER_FLAGS="--prefer-stable --prefer-lowest" SYMFONY_DEPRECATIONS_HELPER="max[direct]=0"
        
          # Test the latest stable release
        - php: 7.4
          env: COVERAGE=true PHPUNIT_FLAGS="-v --coverage-text"

          # Latest commit to master
        - php: 7.4
          env: STABILITY="dev"

    allow_failures:
          # Dev-master is allowed to fail.
        - env: STABILITY="dev"

before_install:
    - if [[ $COVERAGE != true ]]; then phpenv config-rm xdebug.ini || true; fi
    - if ! [ -z "$STABILITY" ]; then composer config minimum-stability ${STABILITY}; fi;
    - if ! [ -v "$DEPENDENCIES" ]; then composer require --no-update ${DEPENDENCIES}; fi;
    # Prevent '/home/travis/build/BooleanType/symfony_knpu_lorem_ipsum_bundle/composer.phar: Permission denied'
    # https://nofluffjuststuff.com/blog/brian_kotek/2013/06/grails_travis_ci_and_permission_denied
    - chmod +x composer.phar

install:
    - composer update ${COMPOSER_FLAGS} --prefer-dist --no-interaction
    - ./vendor/bin/simple-phpunit install

script:
    - composer validate --strict --no-check-lock
    # simple-phpunit is the PHPUnit wrapper provided by the PHPUnit Bridge component and
    # it helps with testing legacy code and deprecations (composer require symfony/phpunit-bridge)
    - ./vendor/bin/simple-phpunit $PHPUNIT_FLAGS

Can you please help me with this? It's the last step for me to say, that my bundle works 100% well :)

Hey Boolean!

Your bundle is using Symfony 5.2 (phpunit-bridge and framework) and this course was developed under Symfony 4. The way to work with PHPUnit has changed so you will have to update the commands on your TravisCI config. Double-check that after install your bundle's vendor you have a this file bin/phpunit if you do, then you only have to execute it, the first time it runs it will install PHPUnit, you may want to cache the installation folder for performance reasons but that's another topic. Give it a try and let me know if it worked

Cheers!

Hi!
It looks like I don't have bin/.phpunit in my bundle's vendor.
In my <i>local</i> bundle I have the following vendor/bin structure:

│   .phpunit.result.cache
│   simple-phpunit
│   simple-phpunit.bat
│   var-dump-server
│   var-dump-server.bat
│
└───.phpunit
    │   .phpunit-8.3-0.md5
    │   phpunit.xsd
    │
    └───phpunit-8.3-0
        │   .editorconfig
        │   ...

And in Travis CI it looks this way (no .phpunit folder):

$ cd vendor/bin
$ ls -a
.  ..  simple-phpunit  var-dump-server

symfony/phpunit-bridge` is installed In Travis for sure:

$ cd ./vendor/symfony/phpunit-bridge

$ ls -a
.		     composer.json		  Legacy
..		     ConstraintTrait.php	  LICENSE
bin		     CoverageListener.php	  README.md
bootstrap.php	     DeprecationErrorHandler	  SetUpTearDownTrait.php
CHANGELOG.md	     DeprecationErrorHandler.php  SymfonyTestsListener.php
ClassExistsMock.php  DnsMock.php		  TextUI
ClockMock.php	     ExpectDeprecationTrait.php

But ./vendor/bin/simple-phpunit install doesn't work. Maybe, I run this command in wrong dir? 'Cause I've tried another way: I execute simple-phpunit directly in vendor/bin and revert dir back after installation (for correct execution of the follow-up ./vendor/bin/simple-phpunit $PHPUNIT_FLAGS command) ( https://travis-ci.com/github/BooleanType/symfony_knpu_lorem_ipsum_bundle/jobs/486804070 ):

install:
    - composer update ${COMPOSER_FLAGS} --prefer-dist --no-interaction
    - cd vendor/bin
    - ./simple-phpunit
    - cd ../..
    - ls -a

In case of commands above php-unit was installed, but finally I saw <i>"The command "./simple-phpunit" failed and exited with 2 during ."</i> message, which I suppose (but not sure) goes from "simple-phpunit" file (command is "${dir}/simple-phpunit" "$@"). Of course, cd ../.. next command doesn't even execute.

So, I still don't get, why ./vendor/bin/simple-phpunit install doesn't install php-unit and what else I can do to fix it. I've also tried to apply configurations from other bundles (like knpuniversity/KnpUGuardBundle or knpuniversity/oauth2-client-bundle), but no success.

Hmm, that's odd. I'd expect you to have a bin/phpunit file after have installed symfony/phpunit-bridge on version 5, and then, after running phpunit you should get a bin/.phpunit folder with the current PHPUnit installation. That's how the symfony-phpunit-bridge works

Can you double check if you got the bin/.phpunit directory after executing PHPUnit?

Here is my changed install section ( https://travis-ci.com/github/BooleanType/symfony_knpu_lorem_ipsum_bundle/jobs/488857369 ):

install:
    # Here symfony/phpunit-bridge (v5.2.0) is installed:
    - composer update ${COMPOSER_FLAGS} --prefer-dist --no-interaction 
    - cd ./vendor/bin/
    # For ls -a I see the following: .  ..  simple-phpunit  var-dump-server
    # There is no phpunit file - only simple-phpunit
    - ls -a
    # Return to source folder:
    - cd ../..
    # Try to install phpunit with simple-phpunit file. See a lot of warnings like 
    # "No such file or directory (errno 2) in /home/travis/build/BooleanType/symfony_knpu_lorem_ipsum_bundle/vendor/symfony/phpunit-bridge/bin/simple-phpunit.php on line 217"
    - ./vendor/bin/simple-phpunit install
    # Want to see if some files/dirs have been occured after command above:
    - cd ./vendor/bin/
    # Still see this: .  ..  simple-phpunit  var-dump-server
    - ls -a
    - cd ../..

Maybe, I do something wrong, but it looks I don't have .phpunit after running ./vendor/bin/simple-phpunit install command.

Hey Boolean_Type,

Hm, your config looks ok to me, but just in case take a look at a similar one that works well: https://github.com/KnpLabs/... - do you see any difference? It works well for that bundle, I see a successful (green) build in January. Looking at your error messages from the output I only can say that most probably your have some incompatibility issues with the installed Symfony's PHPUnit bridge and the version of PHP you use in your Travis. I'd recommend you to try to upgrade the PHPUnit bridge to the latest available or try this config but on a different (lower) PHP version, e.g. 7.3 of 7.2 and see if you will still have same issues, but that's really weird, probably we miss something important in your config if it works for others well.

If you want to dig further - probably take a look at the specific lines in that "simple-phpunit.php" - you can see the exact lines in the error output, it may give you some hits about what's wrong, etc.

It depends on your needs of course, but I'd recommend you to take a look at GitHub Actions instead. You can see that Symfony (and a lot of other bundles/libraries) are moved to it from Travis. I understand, it's not the answer why your config does not work, but it's a good alternative way that's most popular lately.

I hope this helps!

Cheers!

Hah, you see, finally it's passed ( https://travis-ci.com/github/BooleanType/symfony_knpu_lorem_ipsum_bundle/builds/219543164 ).
As I wrote in previous comment ( http://disq.us/p/2ffcp0u ), phpunit was installed successfully, when I executed simple-phpunit <i>directly from it's directory</i>. So, I was close.
What I've done today:

env:
    global:
        ...
        # If not to set XDEBUG_MODE, "SebastianBergmann\CodeCoverage\RuntimeException: XDEBUG_MODE=coverage or xdebug.mode=coverage has to be set" is thrown.
        - XDEBUG_MODE=coverage
...
install:
    - composer update ${COMPOSER_FLAGS} --prefer-dist --no-interaction 
     # Change directory and install phpunit.
    - cd ./vendor/bin/ 
    - ./simple-phpunit install

script:
    # Change directory back to bundle's root.
    - cd ../..
    - ./vendor/bin/simple-phpunit $PHPUNIT_FLAGS

I don't know, why it's working exactly this way, but I'm happy to see green jobs at least :)

Hey Boolean_Type,

Yay awesome job! Thank you for sharing your final solution with others! Though, I still don't see an important change that made it working :/ Anyway, I'm glad you got it working, well done!

Cheers!

Thank you for the reply!
I've tried:
1) to change PHP version (7.2, 7.3, 7.4)
2) to copy travis.yml content from KnpMarkdownBundle to my appropriate file. Also modified it in different ways;
3) my phpunit-bridge is already latest, but I changed to version set in KnpMarkdownBundle;
4) changed phpunit.xml content according to content in KnpMarkdownBundle.
Generally, 68 attempts to run tests in Travis - and no success :-D
Really don't know, what can be wrong. But by and large, it's not a problem, 'cause I wanted it to be successful, only because Travis is used in <i>this cast</i>. I don't use it in real life yet. And thanks for your advice I already know, that I should pay attention to GitHub Actions, not to Travis, if I have a possibility to choose.
Thank you very much for supporting and for such nice cast!

Hi there , hi team,

Thanks for the awesome job you do everyday!

I'm currently working on a new application for my company, this application is kind of the same infrastructure as Carlos Eduardo's commented a year ago. We have multiple clients that need the same product but this one must be configurable for their needs.

In fact, it's not only configurable, because some part of the application work completely differently, so we must be able to override part of the code.

To do this, we followed this tutorial and it looks like it works kinda good.
Unfortunately, we have a strong problem with the JS & CSS files.

We don't know if we need to use Webpack in our bundle to generate the minified JS in the bundle in import them in the main project with "assets:install" or if we should write the JS in the Bundle, require it in the main project and use Webpack there ?

It's probably not easy to understand but I can simplify this : what's the best way to manage the JS files in a bundle ?
And moreover, how to do this in a clean way ? Can I use Webpack in a Bundle ?

Thank again for your job and I hope I have been clear in my questions!
Alex

Hi Ryan,

Noticed that Symfony\Component\Config\Definition\Builder\TreeBuilder has gone through a few changes lately.

If I use:

$treeBuilder = new TreeBuilder();
$rootNode = $treeBuilder->root('package_key');

I get a warning that a tree builder without a root is deprecated since Symfony 4.2

And if I use:

$treeBuilder = new TreeBuilder('package_key');
$rootNode = $treeBuilder->root('package_key');

I get a deprecated since Symfony 4.3 warning.

And If I use:

$treeBuilder = new TreeBuilder('package_key');
$rootNode = $treeBuilder->getRootNode();

It's not valid for versions lower than 4.2.

Does this mean that I should use getRootNode and target only 4.2 and above? Or is there a way round it?

Kind regards,

Nigel

Hey hurnell

You can try something like:

$treeBuilder = new TreeBuilder('package_key');
if (method_exists($treeBuilder, 'getRootNode')) {
    $rootNode = $treeBuilder->getRootNode();
} else {
    $rootNode = $treeBuilder->root('package_key');
}

Cheers!

Hey!! Great course! Thanks.

Here's the thing... I watched all this tutorial with the major goal to heal a doubt that I'm facing in the last days. We're rebuilding some corporative systems of our customers and what we're aiming is to build one modular ERP system. You know... it is that traditional concept of share some modules between customers, adding customized functionalities where some of them need, add special modules to others, and there it goes...

Before I even know exactly what was and what was the purpose of a Symfony Bundle, I was able to swear that bundles was the right approach to build the modules of our new ERP. But now I'm really confused. One thing that made me confused is that way of dealing with routes. It's really harder to build all the routes inside bundles and config the way they're exposed when compared to the annotations way.
If you could hand me some insights to try to understand what is the best architecture to build this modular ERP with Symfony.
One way I'm tempted to go is to build each module like a totally separated application, and share only the authentication among them. What do you think?

Thanks again!!!

Hey Carlos!

Oh boy - yes, this is a great question! The answer... as always is... it depends :p. And there are several good options. The big "it depends" sorta depends on how you want to "host" the app and how data is stored. For example, consider these 2 extremes:

1) You create one app with one database, and simply segregate everything based on looking up stuff in the database. For example, maybe when you access client1.yourerpsystem.com, you look up the client based on the host name from some Client entity and determine the "look" and enabled features based on flags in there. You more or less just have if statements in your app that hide/show links and deny access to not-enabled features. Pretty much each Entity has a relation back to Client so that you can determine which records are for which client. Or, you can use some tricks to use a different database name for each client to avoid that.

2) Each Client literally has their own, completely independent Symfony application that is deployed to its own server (or however you deploy) with its own database. There is absolutely nothing shared between different clients - and you even maybe deploy them separately (allowing client A to be on version "1.1" of your site and client B to be on version "1.2").

These are the 2 extremes - and there are more options kind of "in the middle". What you need depends a lot on your requirements. System (1) is simpler in some way (just one "deployment" and 1 app to manage) but more complex in other ways (need to separate data via the relation to Client).

A lot of this comes down to: what is the best/worst way to enable/disable features across multiple clients. With situation (2) [or even another version of situation 2 where you have 1 app, but each client has its own kernel with different bundles enabled/disabled]) you *could* enable/disable features by enabling and disabling bundles. One real-world complication to think about is that you would really need to make sure each bundle that can be turned on/off is truly standalone. You would also need to setup your CI system to test the app with all combination of the bundles being on and off, to avoid accidentally relying on some optional feature from a bundle.

So... I'll stop right there - because a lot of the other pros and cons start to just depend on which type of option you are "leaning" towards. I will say one more thing: the "really cool" (but not really that important, imo) advantage to multiple bundles is that when you disable a bundle, all the routes and services of that bundle are literally not included in your application. That means there is no performance penalty for including unused features in your cache. But, that performance impact may not be that big, and the result is probably more complexity. I have built one of these apps before, and it was more like option (A). It WAS still complex... because feature flags are complex, but it was doable from day 1.

If you have more questions after all that long talking, let me know!

Cheers!

Hey Ryan!! Thanks for another lesson!!

Since our customers all have their own IT infrastructure, all ERP systems will be deployed separately.
We're thinking that each module (CRM, Finance, Sales, etc) could be a separated Symfony application, sharing the same database (tables like crm_, fin_, sal_, etc) and one core module to orchestrate the Security (authentication), configuration and the main menu with the links to each application. So it would be like this:

/erpname-core
/erpname-crm
/erpname-finance
/erpname-sales
/erpname-etc..

Then if some customer doesn't need the "sales" module for instance, we just don't deploy it.
The authentication inside each module could be with the API Token idea.

Then I'll use the Symfony Bundles only to share codes that would be used by all modules, something like erpname-utilsbundle or erpname-basebundle.

Can you imagine some negative points in using this approach?

Hey Carlos!

Hmm, actually, this sounds really nice to me :). The downside is that multiple applications means multiple things to deploy and more to manage (e.g. upgrading Symfony versions multiple times, once for each version). Sl obviously, your deploy mechanism will need to be very automated to ease this. Also, it depends on how "big" version 1 needs to be and how many resources you have. For example, if you were a small startup, you might need to reduce the complexity somewhat (maybe). But if you're a bit bigger or already know you will have a certain number of customers, this approach makes more sense.

So, the downside as I mentioned would just be complexity (a lot of moving pieces to keep track of). You could reduce that by building each application into one project. What I mean is, you would have just 1 Symfony app, but you would have multiple "kernels". This is a bit more advanced, but you would have a "CRM" kernel that boots up all the bundles it needs and runs 100% independent, and another "Finance" kernel that does the same. These would function like separate apps, but living in the same codebase (so you wouldn't need to manage so many shared bundles across many apps, or worry about upgrading Symfony in multiple apps).

Cheers!

Great!! Thank you very much!!! I'll that a look at this multiple kernels architecture.