Hi, We use jenkins as continuous integration system that (at every commit) checkout the project source from git, launch composer update, execute unit tests and deploy to staging server.

Yesterday we removed koolreport pro from our repositories and start to require it with coposer but after 1 hour the builds started to fail because of token expiration.

We need a permanent token.

So are you saying that the token doesn't expire anymore? We use GitLab for CI and are concerned we'll hit the same problem

Heya

Hmm. It doesn't seem to work (I just bought the Excel package FYI). I had no problem downloading locally with auth.json etc. I've added auth.json into my repo so that the unit test runner has the ability to download using the same code.

This is what I'm seeing on the Pipeline when we try to run unit tests from within a Docker container:

Thanks for any help you can give.

  - Installing koolreport/core (4.0.0): Downloading (connecting...)Downloading (100%)         
  - Installing markbaker/matrix (1.1.4): Downloading (connecting...)Downloading (0%)           Downloading (5%)Downloading (10%)Downloading (15%)Downloading (20%)Downloading (25%)Downloading (30%)Downloading (35%)Downloading (40%)Downloading (45%)Downloading (50%)Downloading (55%)Downloading (60%)Downloading (65%)Downloading (70%)Downloading (75%)Downloading (80%)Downloading (85%)Downloading (90%)Downloading (95%)Downloading (100%)
  - Installing markbaker/complex (1.4.7): Downloading (connecting...)Downloading (0%)           Downloading (25%)Downloading (35%)Downloading (60%)Downloading (70%)Downloading (95%)Downloading (100%)
  - Installing phpoffice/phpspreadsheet (1.8.1): Downloading (connecting...)Downloading (0%)           Downloading (5%)Downloading (10%)Downloading (15%)Downloading (20%)Downloading (25%)Downloading (30%)Downloading (35%)Downloading (40%)Downloading (45%)Downloading (50%)Downloading (55%)Downloading (60%)Downloading (65%)Downloading (70%)Downloading (75%)Downloading (80%)Downloading (85%)Downloading (90%)Downloading (95%)Downloading (100%)
  - Installing koolreport/excel (6.0.0): Downloading (connecting...)Downloading (100%)             Failed to download koolreport/excel from dist: The checksum verification of the file failed (downloaded from https://repo.koolreport.com//dist/koolreport/excel/koolreport-excel-a5d55b459ab0a8daba9722688ceab73b64af78da-zip-c30ad3.zip)
    Now trying to download from source
  - Installing koolreport/excel (6.0.0): Cloning a5d55b459a

                                                                                                                                                                                                                                                                                                    
  [RuntimeException]                                                                                                                                                                                                                                                                                
  Failed to execute git clone --no-checkout 'git@github.com:koolreport/excel.git' '/builds/abc/vendor/koolreport/excel' && cd '/builds/abc/vendor/koolreport/excel' && git remote add composer 'git@github.com:koolreport/excel.git' && git fetch composer `

Hi David

It's a docker container so it's an entirely fresh install during the unit test process.

I've added the composer clear-cache to the install script.

See results:

I also just double checked - I removed the library from my local and then required it again. It all downloaded fine using that password.

Any other suggestions?

Thanks

Toby

Hi David

It's an expired token but when using Docker on GitLab surely it's always going to be a first time install? Every time it spins up a entirely fresh docker instance of the server to run the unit tests.

Does your authentication technology work with Docker instances?

I don't understand why you don't just stop the token expiring?

I will send the full job script to your email address.

Toby

It works fine on the unit test Docker instance if I use a new token however that doesn't solve my issue. I will see if it still works if I try the unit test pipeline again in one hour and report back.

Ok so that worked! Don't fully understand why, but it worked. Will now try in production. Thanks for your help.

So the unit test with docker on gitlab worked in production yesterday but no longer works today. Are there any other solutions you can suggest? Is there a different auth method to the package we can use please? A permanent token would be ideal.

Safer for you but of no use to your customers!

You really need to say this when selling that it won't work in dockerised environments. Otherwise people are paying for something they can't use.

Aha ok will try that and report back.

Hi that avoids the issue for now but is obviously only a temporary solution so please let us know when you have a longer term fix.

We are also being heavily impacted by this. Automated build systems, our developer local workstations, and our production environment is all broken right now due to this change. We must have a better solution - this is not workable in the long term. Permanent tokens, or even just the ability to manually load files into the vendor folder. The "old way" was working just fine and quite stable. As all of our systems are automated via chef and other tools, having this require manual interaction to deploy code is not a workable solution.

Correct - just putting the files. The file method allowed me to check the latest version into our get repo, and then the composer process would just "overlay" on the folder. This way, no one ever had an issue, and they could just clone, run composer install, and start coding.

As it stands, I have now spent many hours preparing a development VM that I will now have to distribute to many developers around the world, simply because we do not have a way of creating a repository that can both a) be automatically deployed to the cloud and b) be deployed to a local development machine without involving logging in and pushing the "button". I.e. our devs can't just clone from our main git repo anymore and expect to be able to set up the application with "composer install", even though I have the koolreport files in the vendor directory checked into the repo explicitly. This has created a significant headache for us, right as I'm trying to spin up 5 new devs onto our project.

Great composer is supported now, not so great the token expires. All workarounds are annoying... looking at e.g. nova.laravel.com there is a private non expiring token, so composer is fully supported even for this commercial package. Wonder if you could implement this as well?

Following up on this - the "old way" is still different. My autoload is deeply integrated into my framework - I cannot easily do an arbitrary autoload call. In the "old way", I added the koolreport repo via composer, and then copied the "pro" files into the vendor/koolreport folder. This was simple, as I simply added the vendor/koolreport/pro (or whatever it was called) subfolder to my git repo. No issues whatsoever, and it just overlaid on the existing process and did not require an explicit call to autoload.

As it stands, that "old way" no longer works due to the new package structure.

Therefore I am forced to use the new way, which is not very compatible with CI and other approaches.

This still needs to be addressed. We're all running workaround "hacks" as a part of production code, and this has been going on for many months. Needs to be fixed - it is difficult to even stand up a new developer machine with this approach if they check the code out from scratch.

There is no reason whatsoever to have the token expiring. None. I have never heard of any other third-party software company having this restriction, ever. This is an entirely unnecessary constraint, especially when your customers are using some form of cloud hosting or docker. Yes, I can technically install the code directly, but I don't want to do that. I want to use composer. Really, this needs to change.

Edit: Just a quick follow-up. We can still technically use composer if we want to install the package using composer artifacts. (https://getcomposer.org/doc/05-repositories.md#artifact). While the end result is the same as adding it manually to vendor, you can still use things like composer-patches on it, which is useful for some people. Basically, you download the ZIP file, add it to a folder in your repo, then you can set that folder as an artifact repository. Composer will install the package from that ZIP. Again, not perfect, but something temporary for now.

That is great news. Does that include single library licenses, such as inputs or Excel? Or only if you have the entire Pro license?