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
Allow running of "Smoke test release" on draft releases #36997
Conversation
Test Results SummaryCommit SHA: 718ef83
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## trunk #36997 +/- ##
==========================================
- Coverage 46.7% 46.7% -0.0%
Complexity 17188 17188
==========================================
Files 429 429
Lines 64820 64821 +1
==========================================
- Hits 30253 30251 -2
- Misses 34567 34570 +3
|
types: [published] | ||
types: [released, prereleased] |
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.
[Fix]
I noticed in the 7.4.1
and 7.5.0-beta.2
releases that this workflow wasn't triggered after they were made public. I figured it's because these releases may have already been published, and were just updated to be a pre-release
or a release
later on. Therefore, the published
release type wasn't triggered because they were already in a published state to begin with.
Setting the release type to released
and prereleased
I think would be more appropriate. But, is it, @woocommerce/atlas? Thanks 😃
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.
I figured it's because these releases may have already been published, and were just updated to be a
pre-release
or arelease
later on.
I'm not sure that this is the case, as I always make sure to select one of those two before publishing a release... but if released
and prereleased
trigger this workflow as expected, I think this should be okay.
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.
I saw this in the release
event documentation:
Note: The prereleased type will not trigger for pre-releases published from draft releases, but the published type will trigger. If you want a workflow to run when stable and pre-releases publish, subscribe to published instead of released and prereleased.
Might this conflict with this change? 🤔
group: ${{ github.workflow }}-${{ github.ref }} | ||
group: ${{ github.workflow }}-${{ github.event.release.tag_name || inputs.tag }} |
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.
[Fix]
I noticed that the concurrency group was erroneous because the main intention of this workflow is to group the release smoke tests based on the release version (tag) they're testing, not based on github.ref
. Leaving the concurrency group to use github.ref
will cause a smoke test for release 7.5.0
, for example, to unexpectedly cancel the smoke test of another release version.
I fixed it here so that the release smoke tests are grouped by release tag, (whether this tag came from the release
or workflow_dispatch
event) thereby preventing concurrent release smoke tests on different tags/versions from cancelling each other.
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.
Good catch! 🙌
created: ${{ steps.created-at.outputs.created }} | ||
steps: | ||
- name: Validate tag | ||
if: ${{ github.event_name == 'workflow_dispatch' }} | ||
env: | ||
GH_TOKEN: ${{ github.token }} | ||
run: gh release view "${{ github.event.inputs.tag }}" --repo=woocommerce/woocommerce | ||
GH_TOKEN: ${{ secrets.E2E_GH_TOKEN }} |
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.
As noted in the PR description, I replaced the default github.token
with E2E_GH_TOKEN
. You would see similar diffs like this throughout this PR.
- name: Get tag | ||
uses: actions/github-script@v6 | ||
id: tag | ||
with: | ||
result-encoding: string | ||
script: | | ||
console.log( "${{ github.event_name }}" ); | ||
return "${{ github.event.release.tag_name }}" || "${{ github.event.inputs.tag }}" | ||
- name: Get tag from triggered event | ||
id: get-tag | ||
env: | ||
RELEASE_TAG: ${{ github.event.release.tag_name || inputs.tag }} | ||
run: | | ||
echo "Triggered event: ${{ github.event_name }}" | ||
echo "Tag from event: $RELEASE_TAG" | ||
echo "tag=$RELEASE_TAG" >> $GITHUB_OUTPUT |
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.
[Fix]
The return
line was erroneous because the ||
should be inside ${{ }}
. Fixed it here by doing just that. Also removed the use of the actions/github-script
action in order to simplify the logic of this step and make it more readable (I hope 🤞) .
uses: aws-actions/configure-aws-credentials@v1 | ||
uses: aws-actions/configure-aws-credentials@v1-node16 |
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.
[Fix]
This fixes the node v12 deprecation messages.
if ( GITHUB_TOKEN ) { | ||
requestConfig.headers.Authorization = `Bearer ${ GITHUB_TOKEN }`; | ||
} |
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.
The changes in this update-woocommerce.spec.js
file centers around this particular line. This makes sure that the supplied token will be used when downloading the woocommerce.zip
file from a draft release.
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.
👍 nice job. I verified that this selected the correct asset with a draft release that I created. The smoke tests themselves failed for various reasons unrelated to this PR (such as my tag name, 7.4.1-test
not matching the version from the asset I created, 7.4.1
), but I believe that's expected given the package that I used.
types: [published] | ||
types: [released, prereleased] |
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.
I figured it's because these releases may have already been published, and were just updated to be a
pre-release
or arelease
later on.
I'm not sure that this is the case, as I always make sure to select one of those two before publishing a release... but if released
and prereleased
trigger this workflow as expected, I think this should be okay.
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.
Based on Jonathan's validation, this is looking good!
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.
Looks good to me @rodelgc!
Based on this change, it would be great if we could confirm that smoke tests also run on the following scenarios:
- Release is directly published, without any draft previous state.
- Draft release is published, in other words, a draft release is created first (so smoke tests would be run considering the new changes from this PR), but once we remove the draft state and it becomes an actual release, smoke tests should be run again if I'm not wrong).
This way we would cover potential regression issues related to the event triggers change.
types: [published] | ||
types: [released, prereleased] |
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.
I saw this in the release
event documentation:
Note: The prereleased type will not trigger for pre-releases published from draft releases, but the published type will trigger. If you want a workflow to run when stable and pre-releases publish, subscribe to published instead of released and prereleased.
Might this conflict with this change? 🤔
group: ${{ github.workflow }}-${{ github.ref }} | ||
group: ${{ github.workflow }}-${{ github.event.release.tag_name || inputs.tag }} |
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.
Good catch! 🙌
718ef83
It actually did @alopezari! Thanks for bringing this up. When I tested it in a private repo, the workflow indeed wasn't triggered when I saved the release as a draft first, then published it as a To fix this, I pushed 718ef83 so that the release types are now
Workflow wasn't triggered on the scenario where an already published non-latest release was changed to Ready again for another review. |
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.
Save a draft first, then published as a Prerelease
Save a draft first, then published without checking any of the checkboxes in the GitHub UI
Save a draft first, then published as a Latest release
Published as a Prerelease directly, didn't create a draft
Published directly without checking any checkboxes, didn't create a draft
Published directly as a Latest release, didn't create a draft
Start with an already published release, then update it to a Prerelease
Start with an already published pre-release, then update it to a Latest release
Start with an already published pre-release, then update it to a release (without checking Latest)
Thanks for such extensive testing of this change @rodelgc!
I'm approving this PR 👍
If @jonathansadowski & @nigeljamesstevenson are happy with the latest change, I'm happy to merge this 👍 |
@alopezari - Great spot on noticing:
and amazing testing all the combinations @rodelgc ! - This is looking great 😊 |
Awesome, thanks @nigeljamesstevenson! I'll merge this 👍 |
All Submissions:
Changes proposed in this Pull Request:
Closes #36998.
This PR would allow the
Smoke test release
workflow to be run on a draft release. Also, it contains a few several fixes in the workflow file.The main reason why the
Smoke test release
workflow previously couldn't run on draft releases was because it's using the defaultgithub.token
when retrieving the list of releases. Since this token has limited permissions, it can only access releases/pre-releases that are already published.To fix this, the
Smoke test release
workflow now uses the sameE2E_GH_TOKEN
used in other workflows. With this token, draft releases can already be accessed.How to test the changes in this Pull Request:
woocommerce.zip
asset, andtest-pr-36997
.Smoke test release
page.e2e/release-include-drafts
.If you're taken to a 404 page, chances are the reports are still being uploaded. Wait for a few more minutes, then refresh the page.
Other information:
pnpm --filter=<project> changelog add
?FOR PR REVIEWER ONLY: