Page MenuHomePhabricator

Test Kitchen UI login mechanism is not bypassed when running as part of a local MediaWiki instance, via TestKitchen `devserver` local environment
Closed, ResolvedPublic2 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

Configure and run a MediaWiki environment along with the TestKitchen devserver local environment ( according to https://wikitech.wikimedia.org/wiki/Test_Kitchen/Local_development_setup#Configuring_MediaWiki_to_use_the_Test_Kitchen_local_development_environment).

A local instance of Test Kitchen UI will be available at http://localhost:8086

What happens?:

That local instance of Test Kitchen UI should run with its login mechanism deactivated, but it's active. Login mechanism should only be running in production-like environments (staging and production). When Test Kitchen UI is running locally in development mode, the application should bypass its own login mechanism

What should have happened instead?:

As mentioned before, Test Kitchen UI should be running without its own login mechanism. The list of instruments/experiments should be the first page that any user should see when browsing to http://localhost:8086

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Test Kitchen UI v1.2.3. It's not an issue related to any specific version though. It's related to the local environment

Other information (browser name/version, screenshots, etc.):

Event Timeline

Sfaci set the point value for this task to 2.
Sfaci added a project: Essential-Work.

Change #1244716 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/extensions/TestKitchen@master] devserver: Updated to use test-kitchen:dev docker image

https://gerrit.wikimedia.org/r/1244716

sfaci opened https://gitlab.wikimedia.org/repos/data-engineering/test-kitchen/-/merge_requests/300

Updated blubber file to build an additional docker image for local development purposes

cjming merged https://gitlab.wikimedia.org/repos/data-engineering/test-kitchen/-/merge_requests/300

Updated blubber file to build an additional docker image for local development purposes

Change #1244716 merged by jenkins-bot:

[mediawiki/extensions/TestKitchen@master] devserver: Updated to use test-kitchen:dev docker image

https://gerrit.wikimedia.org/r/1244716

After configuring the pipeline to create two different images: one for production and a different one for local development purposes, we have three images after creating a tag for the v1.2.4 release:

  • test-kitchen:dev: Which refers to the local development docker image
  • test-kitchen:latest: Which refers to the latests production docker image
  • test-kitchen:v1.2.4: Which it's not clear who refers to. It seems two publish steps in the pipeline build an image with this suffix so, at the end of the process, it's not clear which image it's

I think we should keep polishing the configuration of the pipeline to have something more clear and explicit:

  • test-kitchen:v1.2.4-prod
  • test-kitchen:latest-dev
  • test-kitchen:latest-prod

phuedx merged https://gitlab.wikimedia.org/repos/data-engineering/test-kitchen/-/merge_requests/304

Fixing the typo that prevent the pipeline from generating the proper docker images

Change #1250073 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] Test Kitchen UI: Deploy v1.2.4 release to staging

https://gerrit.wikimedia.org/r/1250073

Change #1250074 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] Test Kitchen UI: Deploy v1.2.4 release to production

https://gerrit.wikimedia.org/r/1250074

Change #1250103 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/extensions/TestKitchen@master] devserver: Updated to use the right image for local development

https://gerrit.wikimedia.org/r/1250103

After configuring the pipeline to create two different images: one for production and a different one for local development purposes, we have three images after creating a tag for the v1.2.4 release:

  • test-kitchen:dev: Which refers to the local development docker image
  • test-kitchen:latest: Which refers to the latests production docker image
  • test-kitchen:v1.2.4: Which it's not clear who refers to. It seems two publish steps in the pipeline build an image with this suffix so, at the end of the process, it's not clear which image it's

I think we should keep polishing the configuration of the pipeline to have something more clear and explicit:

  • test-kitchen:v1.2.4-prod
  • test-kitchen:latest-dev
  • test-kitchen:latest-prod

After some attempts and more thinking, the above has changed a bit, and docker images will be built as follows (let's say we are going to deploy test-kitchen v1.2.4):

  • v1.2.4-dev: It will be the specific image for local development purpose
  • v1.2.4-prod: It will be the specific image for production-like environments (staging and production)
  • latest-dev: It always points to the last one for local development purpose
  • latest-prod: It always points to the last one for production-like environments (staging and production)

Change #1250073 merged by jenkins-bot:

[operations/deployment-charts@master] Test Kitchen UI: Deploy v1.2.4 release to staging

https://gerrit.wikimedia.org/r/1250073

Change #1250074 merged by jenkins-bot:

[operations/deployment-charts@master] Test Kitchen UI: Deploy v1.2.4 release to production

https://gerrit.wikimedia.org/r/1250074

Change #1250103 merged by jenkins-bot:

[mediawiki/extensions/TestKitchen@master] devserver: Updated to use the right image for local development

https://gerrit.wikimedia.org/r/1250103