Can't use module on SC platform about silverstripe-maintenance HOT 21 OPEN

@andrewandante might get someone from his team to look into this maybe? :)

from silverstripe-maintenance.

Excuse the very much internal reference in an open source issue - but given that this is likely installed on a number of projects in on the Silverstripe Cloud platform, I'm hoping we can use it to elicit some feedback from others.

from silverstripe-maintenance.

I count this module being used on 24 production environments on our own SC platform.

from silverstripe-maintenance.

I believe what I'm experiencing is related, just started happening for one of my SC sites.
Error: E_WARNING: chdir(): Permission denied (errno 13)

SS had a look and could trace it down to this module, but couldn't tell me why the permission error was happening.

From SS
Odd, this is part of the UpdatePackageInfoTask in the silverstripe-maintenance module and its coming up during the queued job run but the task is not being run.

https://github.com/bringyourownideas/silverstripe-composer-update-checker/blob/master/src/Extensions/ComposerLoaderExtension.php#L111-L127

from silverstripe-maintenance.

Hey @rafaeldsousa, what version of this module (bringyourownideas/silverstripe-maintenance)
and bringyourownideas/silverstripe-composer-update-checker are you running?

from silverstripe-maintenance.

Hi @brynwhyman
bringyourownideas/silverstripe-maintenance - 2.3.1

bringyourownideas/silverstripe-composer-update-checker - 2.0.3

from silverstripe-maintenance.

Just to add - I've just seen this behaviour. It breaks all dev/tasks for me, because composer isn't installed on the SCP servers. This means that neither HOME or COMPOSER_HOME are defined, and it throws a server error:

error-log.ERROR: Uncaught Exception RuntimeException: "The HOME or COMPOSER_HOME environment variable must be
set for composer to run correctly" at /var/www/mysite/releases/63e07fc364b9f90ab583e83a6f04bb72a26faf20/vendor
/composer/composer/src/Composer/Factory.php line 652 {"exception":"[object] (RuntimeException(code: 0): The HOME 
or COMPOSER_HOME environment variable must be set for composer to run correctly at /var/www/mysite/releases
/63e07fc364b9f90ab583e83a6f04bb72a26faf20/vendor/composer/composer/src/Composer/Factory.php:652)"}

from silverstripe-maintenance.

@michalkleiner shared a theory in a duplicate issue, thinking the usage of the syntax in the prior fix might be off.

See: silverstripe/cwp-recipe-basic#4 (comment)

from silverstripe-maintenance.

I believe this should be closed - seems to be working fine now.

from silverstripe-maintenance.

@GuySartorelli doesn't work for us on CWP nor on AWS with private repos due to some permission issues. If this module is an umbrella module for the security checker and update checker, then the issues still exist.

from silverstripe-maintenance.

with private repos

Is that to say that if you had no private repositories it works fine? If so that would be the difference I think - the project I saw it working with today doesn't have any private repositories.

The other difference I guess being that I was testing the beta at the time, which uses the new major release of composer-update-checker.

from silverstripe-maintenance.

Actually not even private repos, but forks that have entries under repositories key and use a custom dev-branch instead of a tagged version from Packagist.

from silverstripe-maintenance.

Okay. So there are situations where it doesn't work. Does it work for you with the "happy path" i.e. no custom branches or repository replacements or anything, just 1:1 public packagist entries?

from silverstripe-maintenance.

I don't think we even have a project like that on SCPS/AWS, there's always something that requires a fork in the plethora of modules we use.

from silverstripe-maintenance.

Fair enough. I'll try make some time to do some experimentation.

from silverstripe-maintenance.

Any updates on this ? still happens a lot on SC. For now the only thing we've able to do was to ignore the error permanently so that our logs don't get flooded with entries of this.

from silverstripe-maintenance.

Before I do... 😉

Just want to confirm exactly what the issue is that we are trying to validate.

Seems that the point of this module is to tell the user when there are updates available for the composer packages installed.

It's currently not working on SC boxes because neither HOME or COMPOSER_HOME is set? Is that still true? If so, is a workaround to add one of those as an environment variable?

Or have we now pivoted to "it doesn't work if there are private repos or we are using a fork"? In this case, what's the expected behaviour - for a private repo, it should simply skip it? For a fork, are we expecting notices about the main repo, or the fork, or just to skip it as well?

It feels to me like these can be handled in the module code, rather than through server configuration - if it should work with the above two scenarios, but is relying on composer-based auth, then it's never going to work on SC, because we won't be adding composer to the web boxes just for this. I'd advocate for configuration along the lines of skip_forks: true and skip_private: true that should be toggled for SC.

Always open to discussions, let me know your thoughts. ❤️

from silverstripe-maintenance.

@andrewandante Personally I've only experienced the Error: E_WARNING: chdir(): Permission denied (errno 13) error, which relates to Michal's comment above. So either having private repos or non packagist tagged modules will trigger this issue.
I guess for this scenario having the ability to skip_forks and skip_private repos could work.

from silverstripe-maintenance.

Looks like the above is being attempted at #170

from silverstripe-maintenance.