Reuse B&D artifact in test-playwright.yml#252
Conversation
| default: '' | ||
| required: false | ||
| type: string | ||
| BUILD_WORKFLOW_FILENAME: |
There was a problem hiding this comment.
This one is odd in my opinion. It seems to be used as a fallback when no TESTED_ARTIFACT_SLUG is passed (because it is optional).
But the fallback hinges on the assumption that whatever other (non-build-and-distribute) build workflow also produces an artifact. And that said artifact cannot be referenced with a predictable name (convention or workflow output)
Is there even a second build workflow where these constraints apply?
Maybe I lack the full picture, but my gut feeling would be to make this "named artifact only" and reduce the complexity.
There was a problem hiding this comment.
In Mollie repo the WF which calls B&D is:
Name: Create release package
Filename: release.yml
|
|
||
| - name: Resolve tested artifact run ID | ||
| id: resolve-artifact-run-id | ||
| if: ${{ inputs.TESTED_ARTIFACT_SLUG != '' }} |
There was a problem hiding this comment.
This is supposed to run when the slug is NOT passed, right?
There was a problem hiding this comment.
Opposite 🤔: supposed to run only if the slug is passed. This WF is also used for tests of websites which are deployed to static test envs - in this case there's no artifact
- Rename TESTED_ARTIFACT_SLUG to ARTIFACT_NAME following upload-artifact naming convention - Remove TESTED_ARTIFACT_DIR, hardcode `tests/qa/resources/files` internally
2 participants
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature
What is the current behavior? (You can also link to an open issue here)
Steps for retreiving B&D artifacts are missing.
What is the new behavior (if this is a feature change)?
If TESTED_ARTIFACT_SLUG is provided, the workflow will download the artifact built by B&D and place it as a ready-to-install .zip in TESTED_ARTIFACT_DIR.
tests/qa/resources/filesby default)Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No