-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Spryker 202009 release #398
Conversation
Removed outdated behat extensions and fix symfony/browser-kit version
Removed outdated behat extensions and fix symfony/browser-kit version
d1fe5e4
to
82abe52
Compare
I've rebased this on latest 0.10.x where the spryker build is now passing. Tried
|
…rness-base-php into feature/update-spryker-version
Keep using Pyz namespace as project namespace, as there is some code expecting some templates to be in project namespace and we don't want to copy them over to Inviqa namespace
f2073e0
to
f3edcbe
Compare
yes, just desperate to make it green first 😄 Also found a funny thing, in composer.json of demoshop, they have level 5, but in travis etc. they don't use composer script and run the phpstan directly with level 4 🤦 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good 👍
$config[OauthConstants::PRIVATE_KEY_PATH] = 'file://' . APPLICATION_ROOT_DIR . '/config/Zed/dev_only_private.key'; | ||
$config[OauthConstants::PUBLIC_KEY_PATH] = 'file://' . APPLICATION_ROOT_DIR . '/config/Zed/dev_only_public.key'; | ||
$config[OauthConstants::ENCRYPTION_KEY] = '6Go9YRlbogOQyHpGDkydw8ejC0Z36FboKkFL7mybT0mxB3Oz'; | ||
$config[OauthConstants::OAUTH_CLIENT_SECRET] = 'xN7uUeDzDpYtlp6oTrtC6aHGdA9Cy0gjF6hDaatiRkNyHEoc'; | ||
$config[AuthConstants::AUTH_DEFAULT_CREDENTIALS]['yves_system']['token'] = 'VEOJWp1gsANquUEiGT7pUJdmmS0cnLLCZZKZoiRUAGRyZtUUhNVuTUSeJ8Zz1i5N7ddwv9shJXGTwVmB'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #446 to convert these values to secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, we can't release this PR as a harness version without that though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true. I'm happy to work on that ticket and create a child PR of this one, but need help to understand how to do it.
I think I can convert these values to workspace encrypted attributes for development env, but not sure how we would generate them during project setup using some twig function, also no idea how to generate sealed secrets for them at run time.
It would be nice if we can pair on it @andytson-inviqa or @kierenevans 😄
@kierenevans the missing configuration secrets are set to null by default (they would be set only for pipeline env). Spryker provides some fix values for those configurations, but only for development env. So this works ok for local development env. But, we are running the CI env in production mode (I guess because we want to use those same images to push for creating pipeline env, instead of recreating them afterwards), so there it can't find values for these configuration secrets and fails. Shouldn't we run the CI env in development mode anyway? as we are installing the development deps into it and running tests too. |
Two purposes of the build: a shippable artifact (docker images, helm charts) and testing if the code is correct and conforms to code quality standards. We build the docker image in production mode so it can be sent as-is to pipeline and production. To provide development tooling for code correctness and quality checks, we run the composer install again in the running "pipeline mode" environment and generate the transfer classes, etc. I feel we should still be testing the installation steps for production still, as it's something the developers will not be testing locally. We can provide some fixed oauth secrets if running in Jenkins, via environment variables in the Jenkinsfile, passing them through in docker-compose.yml from the parent environment (set to |
pipeline.php-base.environment_secrets is expected to be using sealed-secrets so it can't be used in CI = env('OAUTH_CONSUMER_SECRET') isn't relevant in attributes/twig templates as it's only an env var once it's in the docker container |
Sorry, meant services. instead of pipeline. |
I'm guessing is more along the lines you're thinking? |
@kierenevans It's ready for review now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
Fixes #397 and #446
Work done: