clear out unneeded github files from block folder (#44895)

* clear out unneeded github files from block folder

* copy changelog to woocommerce folder

---------

Co-authored-by: Ron Rennick <ronald.rennick@automattic.com>
This commit is contained in:
Ron Rennick 2024-02-29 13:30:56 -04:00 committed by GitHub
parent c84d9d944a
commit ccef3d22f8
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
28 changed files with 8 additions and 1433 deletions

View File

@ -1,46 +0,0 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <support@woo.com>. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/

View File

@ -1,54 +0,0 @@
---
name: "\U0001F41E Bug report"
about: Let us know if something isn't working as you expect it to.
labels: 'type: bug'
---
## Describe the bug
A clear and concise description of what the bug is.
## To reproduce
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
## Expected behavior
A clear and concise description of what you expected to happen.
## Screenshots
If applicable, add screenshots to help explain your problem.
## Environment
### WordPress (please complete the following information):
- WordPress version: [e.g. 5.9]
- Gutenberg version (if installed): [e.g. 12.0.0]
- WooCommerce version: [e.g. 6.1]
- WooCommerce Blocks version: [e.g. 7.0.0]
- Site language:
- Any other plugins installed:
### Desktop (please complete the following information):
- OS: [e.g. macOS, Windows]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]
### Smartphone (please complete the following information):
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Browser [e.g. stock browser, safari]
- Version [e.g. 22]
## Additional context
Add any other context about the problem here.

View File

@ -1,15 +0,0 @@
---
name: "\U0001F4AC Feedback Cart & Checkout Blocks"
about: Submit feedback about the new block-based Cart & Checkout.
labels: "type: feedback", "◼️ block: cart", "◼️ block: checkout"
---
<!--
Thank you for taking the time to leave your feedback on the Cart and Checkout blocks!
We read every single one of these reports and use them as we plan and consider where we focus
future efforts on improving the blocks.
-->
## What do you like about the Cart & Checkout blocks?
## What do you think is missing from the Cart & Checkout blocks?

View File

@ -1,9 +0,0 @@
---
name: '📖 Feedback Documentation'
about: Submit feedback or report an issue about some documentation.
labels: 'type: documentation'
---
<!--
Thank you for taking the time to leave your feedback about the documentation. Please explain your issue or suggestion below.
-->

View File

@ -1,18 +0,0 @@
---
name: "✨ Feature request"
about: If you have an idea to improve an existing WooCommerce + Gutenberg related
feature, please let us know or submit a Pull Request!
labels: "type: enhancement"
---
## Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
## Describe the solution you'd like
A clear and concise description of what you want to happen.
## Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
## Additional context
Add any other context or screenshots about the feature request here.

View File

@ -1,24 +0,0 @@
---
name: "❓ Support Question"
about: If you have a question please see our docs or use our forums, helpdesk, or
Slack Community!
labels: "type: support"
---
We don't offer technical support on GitHub so we recommend using the following:
## Reading our documentation
Usage docs can be found here: <https://woo.com/documentation/woocommerce/>
If you have a problem, you may want to start with the self help guide here: <https://woo.com/document/woocommerce-self-service-guide/>
**Technical support for premium extensions or if you're a Woo.com customer**
from a human being - submit a ticket via the helpdesk
<https://woo.com/contact-us/>
## General usage and development questions
- WooCommerce Slack Community: <https://woo.com/community-slack/>
- WordPress.org Forums: <https://wordpress.org/support/plugin/woocommerce>
- The WooCommerce Help and Share Facebook group

View File

@ -1,5 +0,0 @@
# Reporting Security Issues
The WooCommerce team take security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.
For security related issues and how to report them, please visit the [Automattic Security](https://automattic.com/security/) page.

View File

@ -1,35 +0,0 @@
# Basic set up for three package managers
version: 2
updates:
- package-ecosystem: 'github-actions'
directory: '/'
schedule:
interval: 'monthly'
open-pull-requests-limit: 10
labels:
- "skip-changelog"
- "type: dependencies"
- "github_actions"
# Maintain dependencies for npm
- package-ecosystem: 'npm'
directory: '/'
schedule:
interval: 'weekly'
open-pull-requests-limit: 10
labels:
- "skip-changelog"
- "type: dependencies"
- "javascript"
# Maintain dependencies for Composer
- package-ecosystem: 'composer'
directory: '/'
schedule:
interval: 'weekly'
open-pull-requests-limit: 10
labels:
- "skip-changelog"
- "type: dependencies"
- "php"

View File

@ -1,151 +0,0 @@
[
{
"name": "category: accessibility",
"color": "5804ea",
"aliases": [ "scope: accessibility" ],
"description": "The issue/PR is related to accessibility."
},
{
"name": "category: duplicate",
"color": "5804ea",
"aliases": [],
"description": "The issue/PR is a duplicate of another issue."
},
{
"name": "category: i18n",
"color": "5804ea",
"aliases": [ "scope: i18n" ],
"description": "The issue/PR is related to internationalization."
},
{
"name": "category: performance",
"color": "5804ea",
"aliases": [ "type: performance" ],
"description": "The issue/PR is related to performance."
},
{
"name": "category: refactor",
"color": "5804ea",
"aliases": [ "type: refactor" ],
"description": "The issue/PR is related to refactoring."
},
{
"name": "category: won't fix",
"color": "5804ea",
"aliases": [],
"description": "The issue wont be fixed."
},
{
"name": "good first issue",
"color": "1eff05",
"aliases": [ "type: good first issue", "[Type] Good First Change" ],
"description": "The issue is a good candidate for the first community contribution/for a newcomer to the team."
},
{
"name": "impact: high",
"color": "d73a4a",
"aliases": [],
"description": "This issue impacts a lot of users as reported by our Happiness Engineers."
},
{
"name": "needs design",
"color": "ed95d2",
"aliases": [ "action: needs design", "[Status] Needs Design" ],
"description": "The issue requires design input/work from a designer."
},
{
"name": "needs docs",
"color": "ed95d2",
"aliases": [],
"description": "The issue/PR requires documentation to be added."
},
{
"name": "needs feedback",
"color": "ed95d2",
"aliases": [ "action: needs feedback", "[Status] Needs Discussion" ],
"description": "The issue/PR needs a response from any of the parties involved in the issue."
},
{
"name": "needs tests",
"color": "ed95d2",
"aliases": [ "scope: tests", "[Type] E2E" ],
"description": "The issue/PR needs tests before it can move forward."
},
{
"name": "priority: critical",
"color": "d73a4a",
"aliases": [ "[Pri] CRITICAL" ],
"description": "The issue is critical—e.g. a fatal error, security problem affecting many customers."
},
{
"name": "priority: high",
"color": "d93f0b",
"aliases": [ "[Pri] High" ],
"description": "The issue/PR is high priority—it affects lots of customers substantially, but not critically."
},
{
"name": "priority: low",
"color": "e2f78c",
"aliases": [ "[Pri] Low" ],
"description": "The issue/PR is low priority—not many people are affected or theres a workaround, etc."
},
{
"name": "status: blocked",
"color": "d73a4a",
"aliases": [ "status: blocked", "[Status] Blocked" ],
"description": "The issue is blocked from progressing, waiting for another piece of work to be done."
},
{
"name": "status: on hold",
"color": "d93f0b",
"aliases": [],
"description": "The issue is currently not prioritized."
},
{
"name": "type: bug",
"color": "d73a4a",
"aliases": [ "type: bug", "[Type] Bug" ],
"description": "The issue is a confirmed bug."
},
{
"name": "type: documentation",
"color": "0075ca",
"aliases": [ "scope: documentation" ],
"description": "This issue is a request for better documentation."
},
{
"name": "type: enhancement",
"color": "0075ca",
"aliases": [ "type: enhancement", "[Type] Enhancement" ],
"description": "The issue is a request for an enhancement."
},
{
"name": "type: question",
"color": "0075ca",
"aliases": [ "type: support", "[Type] Question" ],
"description": "The issue is a question about how code works."
},
{
"name": "type: task",
"color": "0075ca",
"aliases": [ "[Type] Task" ],
"description": "The issue is an internally driven task (e.g. from another A8c team)."
},
{
"name": "type: technical debt",
"color": "0075ca",
"aliases": [ "[Type] Technical Debt" ],
"description": "This issue/PR represents/solves the technical debt of the project."
},
{
"name": "type: compatibility",
"color": "0075ca",
"aliases": [ "[Type] Compatibility" ]
},
{
"name": "status: needs review",
"color": "fbca04",
"aliases": [ "[Status] Needs Review" ],
"description": "PR that needs review"
}
]

View File

@ -1,106 +0,0 @@
# Patch release steps
The release pull request has been created! This checklist is a guide to follow for the remainder of the patch release process. You can check off each item in this list once completed.
- [ ] Checkout the release branch locally.
## Initial Preparation
- [ ] Close the milestone of the release you are going to ship. That will prevent newly approved PRs to be automatically assigned to that milestone.
- [ ] Check that the release automation correctly added the changelog to `readme.txt`
- [ ] Ensure you pull your changes from the remote, since GitHub Actions will have added new commits to the branch.
- [ ] Check the version and date in the changelog section within `readme.txt`, e.g. `= {{version}} - YYYY-MM-DD =`
- [ ] Check the changelog matches the one in the pull request description above.
- [ ] Run `npm run change-versions` to update the version numbers in several files. Write the version number you are releasing: {{version}}.
- [ ] Update compatibility sections (if applicable).
- [ ] Cherry-pick into the release branch all fixes that need to be included in this release (assuming they were merged into `trunk`).
- [ ] Push above changes to the release branch.
## Create the Testing Notes
- [ ] Run `npm ci`
- [ ] Run `npm run package-plugin:deploy`. This will create a zip of the current branch build locally.
- Note: The zip file is functionally equivalent to what gets released except the version bump.
- [ ] Create the testing notes for the release.
- [ ] For each pull request that belongs to the current release, grab the `User Facing Testing` notes from the PR's description.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- [ ] Add the notes to `docs/internal-developers/testing/releases`
- [ ] Update the `docs/internal-developers/testing/releases/README.md` file index.
- [ ] Copy a link to the release zip you created earlier into the testing notes. To generate the link you can upload the zip as an attachment in a GitHub comment and then just copy the path (without publishing the comment).
- [ ] Commit and push the testing docs to the release branch.
## Smoke testing
Each porter is responsible for testing the PRs that fall under the focus of their own team. Shared functionality should be tested by both porters. This means that the Rubik porter will mostly test checkout blocks and Store API endpoints, while the Kirigami porter will test the product related blocks and Store API endpoints.
- [ ] Smoke test the built release zip. Refer to the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md) for critical functionality.
- [ ] Test in a clean environment. Create a Jurassic.Ninja site, upload your zip, then smoke test it.
- [ ] Ask the porters of Rubik/Kirigami/Origami to test the built zip as well and to approve the PR if everything looks good. We recommend creating threads of p2 to track which test cases were tested.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
After testing:
- If all PRs are testing as expected, continue with the release.
- If one or more PRs are not testing as expected: ping the PR authors and the porter of the relevant team and ask them if the change is a release blocker or not (you can also ping the team lead if any of them is not available). In general, if it's not a regression or there is no product/marketing reason why that PR is a blocker, all other PRs should default to not being blockers.
- If there are blockers: stop the release and ask the PR author to fix them. If the PR author is AFK, ping the porter of their team.
- If some PRs are not testing as expected but they are not blockers: revert the relevant commits, remove the changes from testing steps and changelog, open an issue (or reopen the original one) and proceed with the release.
- If minor issues are discovered during the testing, each team is responsible for logging them in Github.
## Deploy the update
- [ ] Make sure you've got `hub` installed (`brew install hub`) and make sure `hub api user` returns JSON with information about your GitHub user account. If it doesn't:
- Create a [GitHub access token](https://github.com/settings/tokens) with the `repo` permission.
- Set the environment variables: `GITHUB_USERNAME` with your GitHub Username, and `GITHUB_TOKEN` with the token you just generated. (You may want to add these to `.bashrc` or the equivalent)
- Run `hub api user` again and ensure JSON with information about your GitHub user account is returned.
- [ ] Execute `npm run deploy`
- **ALERT**: This script will ask you if this release will be deployed to WordPress.org. You should only answer yes for this release **if it's the latest release and you want to deploy to WordPress.org**. Otherwise, answer no. If you answer yes, you will get asked additional verification by the `npm run deploy` script about deploying a patch release to WordPress.org.
## If this release is deployed to WordPress.org
- [ ] An email confirmation is required before the new version will be released, so check your email in order to confirm the release.
- [ ] Edit the [GitHub release](https://github.com/woocommerce/woocommerce-gutenberg-products-block/releases) and copy changelog into the release notes. Ensure there is a release with the correct version, the one you entered above.
- [ ] The `#woo-blocks-repo` slack instance will be notified about the progress with the WordPress.org deploy. Watch for that. If anything goes wrong, an error will be reported and you can followup via the GitHub actions tab and the log for that workflow.
- [ ] After the wp.org workflow completes, confirm the following
- [ ] Confirm svn tag is correct, e.g. [{{version}}](https://plugins.svn.wordpress.org/woo-gutenberg-products-block/tags/{{version}}/)
- [ ] Changelog, Version, and Last Updated on [WP.org plugin page](https://wordpress.org/plugins/woo-gutenberg-products-block/) is correct.
- [ ] Confirm [Woo.com plugin page](https://woo.com/customize/) is updated. Note: this can take several hours, feel free to check it the following day.
- [ ] Download zip and smoke test.
- [ ] Test updating plugin from previous version.
## After Workflow completes
- [ ] Move the changes to the changelog, testing steps and required versions that you did in the previous steps to `trunk`. You can do so copy-and-pasting the changes in a new commit directly to `trunk`, or cherry-picking the commits that introduced those changes.
- [ ] Update the schedules p2 with the shipped date for the release (PdToLP-K-p2).
- [ ] Edit the GitHub milestone of the release you just shipped and add the current date as the due date (this is used to track ship date as well).
## Pull request in WooCommerce Core for Package update
This only needs done if the patch release needs to be included in WooCommerce Core. Reviewing and merging the PR is your team's responsibility, except in the case of `Fix Release Request`. In this case, the WooCommerce release manager reviews and merges the PR.
- [ ] Create a pull request for updating the package in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/747cb6b7184ba9fdc875ab104da5839cfda8b4be/plugins/woocommerce/composer.json) for the Woo Blocks package to the version you are releasing. Reviewing and merging the PR is your team's responsibility. [See this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Set the base branch (the branch that your PR will be merged into) to the correct one. It must be: - `trunk` if the WC Blocks version you are releasing is higher than the one in core (you can find the current WC Blocks version in core in `plugins/woocommerce/composer.json`) - `release/x.y` if the WC Blocks version in core is higher than the one you are releasing (`x.y` must be the version of WC core that will include the version of WC Blocks you are releasing)
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry well always use `patch`. For the changelog enter "Update WooCommerce Blocks to X.X.X".
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
### Testing the PR
- [ ] Build WC core from that branch with `pnpm run --filter='woocommerce' build ` (you might need to [install the dependencies first](https://github.com/woocommerce/woocommerce#prerequisites)) and:
- [ ] Make sure the correct version of WC Blocks is being loaded. This can be done testing at least one of the testing steps from the release.
- [ ] Complete the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md).
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
## Publish Posts
You only need to post public release announcements and update relevant public facing docs if this patch release is deployed to WP.org. Otherwise, you can skip this section.
- [ ] Post release announcement on [WooCommerce Developer Blog](https://developer.woo.com/category/release-post/woocommerce-blocks-release-notes/).
- Ping porters from each team to know which changelog entries need to be highlighted. Ask them to write a short text and optionally provide a screenshot. They can use previous posts for inspiration, we usually try to highlight new features or API changes.
- Ensure the release notes are included in the post verbatim.
- Don't forget to use category `WooCommerce Blocks Release Notes` for the post.
- [ ] Announce the release internally (`#woo-announcements` slack).
- [ ] Go through the description of the release pull request and edit it to update all the sections and checklist instructions there.
- [ ] Merge this PR into the base branch: `release/x.y.0`.

View File

@ -1,40 +0,0 @@
# Patch release
This is the patch release pull request for WooCommerce Blocks plugin `{{version}}`.
## Changelog
---
```md
{{changelog}}
```
---
## Communication
### Prepared Updates
Please leave a comment on this PR with links to the following:
- [ ] Release announcement (announcement post on https://developer.woo.com/ published after release).
{{#if devNoteItems}}
**Developer Notes** - The following issues require developer notes in the release post:
{{devNoteItems}}
{{/if}}
- [ ] Happiness engineering or Happiness/Support (if special instructions needed).
- [ ] Relevant developer documentation (if applicable).
## Quality
> This section is for things related to quality around the release.
- [ ] Testing Instructions are included in this PR
- [ ] Any performance impacts are documented.
---

View File

@ -1,61 +0,0 @@
<!-- Please do not remove any information from this pull request. Instead, add N/A or leave blank if not applicable -->
## What
Fixes #
## Why
<!-- Describe the reason for your changes. This will help the reviewer and future readers get additional context -->
## Testing Instructions
<!-- Write these steps from the perspective of a "user" (merchant) familiar with WooCommerce. No need to spell out the steps for common setup scenarios (eg. "Create a product"), but do be specific about the thing being tested. Include screenshots demonstrating expectations where that will be helpful. -->
_Please consider any edge cases this change may have, and also other areas of the product this may impact._
1.
2.
3.
* [ ] Do not include in the Testing Notes <!-- Check this box if this PR can't be tested (ie: it makes changes to tests, coding standards, docblocks, etc.). -->
* [ ] Should be tested by the development team exclusively <!-- Check this box if this PR should be tested by the development team exclusively (ie: it doesn't include user-facing changes or it can't be tested without manually modifying the code). -->
## Screenshots or screencast
<!-- Any screenshots of UI changes will be helpful to include here. Leave blank if not applicable. -->
| Before | After |
| ------ | ----- |
| | |
## WooCommerce Visibility
<!-- Check this documentation link (../docs/blocks/feature-flags-and-experimental-interfaces.md) to see if the change is visible in WooCommerce core, part of the feature plugin, or experimental. -->
Required:
* [ ] WooCommerce Core
* [ ] Feature plugin
* [ ] Experimental
* [ ] N/A
## Checklist
Required:
* [ ] This PR has either a `[type]` label or a `[skip-changelog]` label.
* [ ] This PR is assigned to a milestone.
Conditional:
* [ ] This PR has a UI change and has been cross-browser tested at different viewport sizes on both the frontend and in the editor.
* [ ] This PR has a changelog description (if `[skip-changelog]` label is not present).
* [ ] This PR adds/removes a feature flag & I've updated [this doc](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/docs/internal-developers/blocks/feature-flags-and-experimental-interfaces.md).
* [ ] This PR adds/removes an experimental interfaces, and I've updated [this doc](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/docs/internal-developers/blocks/feature-flags-and-experimental-interfaces.md).
* [ ] This PR has been accessibility tested.
* [ ] This PR has had any necessary documentation added/updated.
## Changelog
<!-- Provide a brief, descriptive summary of the changes in this PR. Include potential impacts on different parts of the product. Example: "Updated the checkout process to streamline the experience for users and reduce the number of steps." -->
> Add suggested changelog entry here.

View File

@ -1,3 +0,0 @@
{
"labelsToOmit": [ "skip-changelog", "type: build" ]
}

View File

@ -1,140 +0,0 @@
# Release Steps
The release pull request has been created! This checklist is a guide to follow for the remainder of the release process. You can check off each item in this list once completed.
- [ ] Checkout the release branch locally.
## Initial Preparation
- [ ] Close the milestone of the release you are going to ship. That will prevent newly approved PRs to be automatically assigned to that milestone.
- [ ] Create a milestone for the next version.
- [ ] Manually add the changelog entries of all affected PRs to `readme.txt`. (Technically, this should be an automated process, but it seems to broke recently. Please change this entry back, once the automated process works again.)
- [ ] Ensure you pull your changes from the remote, since GitHub Actions will have added new commits to the branch.
- [ ] Check the version and date in the changelog section within `readme.txt`, e.g. `= {{version}} - YYYY-MM-DD =`
- [ ] Check the changelog matches the one in the pull request description above.
- [ ] Run `npm run change-versions` to update the version numbers in several files. Write the version number you are releasing: {{version}}.
- [ ] Update compatibility sections (if applicable).
- [ ] Update _Requires at least_, _Tested up to_, and _Requires PHP_ sections at the top of `readme.txt`. Note, this should also be the latest WordPress version available at time of release.
- [ ] Update _Requires at least_, _Requires PHP_, _WC requires at least_, and _WC tested up to_ at the top of `woocommerce-gutenberg-products-block.php`. Note, this should include requiring the latest WP version at the time of release. For _WC requires at least_, use L1 (we publicly communicate L0 but technically support L1 to provide some space for folks to update). So this means if the current version of WooCommerce core is 5.8.0, then you'll want to put 5.7.0 here.
- [ ] If necessary, update the value of `$minimum_wp_version` at the top of the `woocommerce-gutenberg-products-block.php` file to the latest available version of WordPress.
- [ ] Check the minimum WP version supported by **WooCommerce Core** (you can find it in [its readme.txt - line `Requires at least`](https://github.com/woocommerce/woocommerce/blob/trunk/plugins/woocommerce/readme.txt#L4)). If necessary, update it in `phpcs.xml`. It would be this line: `<config name="minimum_supported_wp_version" value="5.6" />`.
- [ ] Push above changes to the release branch.
## Create the Testing Notes
- [ ] Run `npm ci`
- [ ] Run `npm run package-plugin:deploy`. This will create a zip of the current branch build locally.
- Note: The zip file is functionally equivalent to what gets released except the version bump.
- [ ] Create the testing notes for the release.
- [ ] For each pull request that belongs to the current release, grab the `User Facing Testing` notes from the PR's description.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- [ ] Add the notes to `docs/internal-developers/testing/releases`
- [ ] Update the `docs/internal-developers/testing/releases/README.md` file index.
- [ ] Copy a link to the release zip you created earlier into the testing notes. To generate the link you can upload the zip as an attachment in a GitHub comment and then just copy the path (without publishing the comment).
- [ ] Commit and push the testing docs to the release branch.
## Smoke testing
Each porter is responsible for testing the PRs that fall under the focus of their own team. Shared functionality should be tested by both porters. This means that the Rubik porter will mostly test checkout blocks and Store API endpoints, while the Kirigami porter will test the product related blocks and Store API endpoints.
- [ ] Smoke test the built release zip. Refer to the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md) for critical functionality.
- [ ] Test in a clean environment. Create a Jurassic.Ninja site, upload your zip, then smoke test it.
- [ ] Ask the porters of Rubik/Kirigami/Origami to test the built zip as well and to approve the PR if everything looks good. We recommend creating threads of p2 to track which test cases were tested.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
After testing:
- If all PRs are testing as expected, continue with the release.
- If one or more PRs are not testing as expected: ping the PR authors and the porter of the relevant team and ask them if the change is a release blocker or not (you can also ping the team lead if any of them is not available). In general, if it's not a regression or there is no product/marketing reason why that PR is a blocker, all other PRs should default to not being blockers.
- If there are blockers: stop the release and ask the PR author to fix them. If the PR author is AFK, ping the porter of their team.
- If some PRs are not testing as expected but they are not blockers: revert the relevant commits, remove the changes from testing steps and changelog, open an issue (or reopen the original one) and proceed with the release.
- If minor issues are discovered during the testing, each team is responsible for logging them in Github.
## Deploy the update
- [ ] Make sure you've got `hub` installed (`brew install hub`) and make sure `hub api user` returns JSON with information about your GitHub user account. If it doesn't:
- Create a [GitHub access token](https://github.com/settings/tokens) with the `repo` permission.
- Set the environment variables: `GITHUB_USERNAME` with your GitHub Username, and `GITHUB_TOKEN` with the token you just generated. (You may want to add these to `.bashrc` or the equivalent)
- Run `hub api user` again and ensure JSON with information about your GitHub user account is returned.
- [ ] Execute `npm run deploy`
- The script will ask you to enter the version number to tag. Please enter the version we're releasing right now. Do not publish any dev tags as a release.
- **ALERT**: This script will ask you if this release will be deployed to WordPress.org. You should answer yes for this release even if it is a pre-release.
- A GitHub release will automatically be created and this will trigger a workflow that automatically deploys the plugin to WordPress.org.
## If this release is deployed to WordPress.org
- [ ] An email confirmation is required before the new version will be released, so check your email in order to confirm the release.
- [ ] Edit the [GitHub release](https://github.com/woocommerce/woocommerce-gutenberg-products-block/releases) and copy changelog into the release notes. Ensure there is a release with the correct version, the one you entered above.
- [ ] The `#woo-blocks-repo` slack instance will be notified about the progress with the WordPress.org deploy. Watch for that. If anything goes wrong, an error will be reported and you can followup via the GitHub actions tab and the log for that workflow.
- [ ] After the wp.org workflow completes, confirm the following
- [ ] Confirm svn tag is correct, e.g. [{{version}}](https://plugins.svn.wordpress.org/woo-gutenberg-products-block/tags/{{version}}/)
- [ ] Changelog, Version, and Last Updated on [WP.org plugin page](https://wordpress.org/plugins/woo-gutenberg-products-block/) is correct.
- [ ] Confirm [Woo.com plugin page](https://woo.com/customize/) is updated. Note: this can take several hours, feel free to check it the following day.
- [ ] Download zip and smoke test.
- [ ] Test updating plugin from previous version.
## After Workflow completes
- [ ] Move the changes to the changelog, testing steps and required versions that you did in the previous steps to `trunk`. You can do so copy-and-pasting the changes in a new commit directly to `trunk`, or cherry-picking the commits that introduced those changes.
- [ ] Run `npm run change-versions` to update the version in `trunk` to the next version of the plugin and include the `dev` suffix. For example, if you released 2.5.0, you should update the version in `trunk` to 2.6.0-dev.
- [ ] Update the schedules p2 with the shipped date for the release (PdToLP-K-p2).
- [ ] Edit the GitHub milestone of the release you just shipped and add the current date as the due date (this is used to track ship date as well).
## Pull request in WooCommerce Core for Package update
**🆕 These steps need to be done for every WooCommerce Blocks release that _isn't_ a patch release**. More information can be found here on why: pdToLP-Of-p2.
- [ ] Remind whoever is porter this week to audit our codebase to ensure this [experimental interface document](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/docs/internal-developers/blocks/feature-flags-and-experimental-interfaces.md) is up to date. See Pca54o-rM-p2 for more details.
- [ ] Create a pull request for updating the package in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/747cb6b7184ba9fdc875ab104da5839cfda8b4be/plugins/woocommerce/composer.json) for the Woo Blocks package to the version you are releasing. Reviewing and merging the PR is your team's responsibility. [See this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry well always use `minor`. For the changelog enter "Update WooCommerce Blocks to X.X.X".
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
The PR description can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
- It lists all the WooCommerce Blocks versions that are being included since the last version that you edited in `plugins/woocommerce/composer.json`. Each version should have a link for the `Release PR`, `Testing instructions` and `Release post` (if available).
- The changelog should be aggregated from all the releases included in the package bump and grouped per type: `Enhancements`, `Bug Fixes`, `Various` etc. This changelog will be used in the release notes for the WooCommerce release. That's why it should only list the PRs that have WooCommerce Core in the WooCommerce Visibility section of their description. Don't include changes available in the feature plugin or development builds.
### Testing the PR
- [ ] Build WC core from that branch with `pnpm run --filter='woocommerce' build ` (you might need to [install the dependencies first](https://github.com/woocommerce/woocommerce#prerequisites)) and:
- [ ] Make sure the correct version of WC Blocks is being loaded. This can be done testing at least one of the testing steps from the release.
- [ ] Complete the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md).
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
### Monthly Releases only
If this is a monthly release, you'll need to do the following steps as well:
- [ ] Make sure you join the `#woo-core-releases` Slack channel to represent Woo Blocks for the release of WooCommerce core this version is included in.
- [ ] Search the release thread of the WooCommerce core version in WooCommerce P2 (example: p6q8Tx-2gl-p2).
- [ ] Subscribe to it, so you are aware of any news/changes.
- [ ] Make sure you are listed as the _Blocks Package_ lead or add yourself if you aren't.
## Publish posts
- [ ] Post release announcement on [WooCommerce Developer Blog](https://developer.woo.com/category/release-post/woocommerce-blocks-release-notes/).
- Ping porters from each team to know which changelog entries need to be highlighted. Ask them to write a short text and optionally provide a screenshot. They can use previous posts for inspiration, we usually try to highlight new features or API changes.
- Ensure the release notes are included in the post verbatim.
- Don't forget to use category `WooCommerce Blocks Release Notes` for the post.
- If any of the PRs in this release is labelled with `needs dev-note`, include it in the post.
- [ ] Document highlights so they can be used in the WC core release post (do this even if the release you are doing is not merged into WC core):
- Check which WC core version will include the WC Blocks release you just did (reference: PdToLP-K-p2).
- Go to the _Release highlights_ page (PdToLP-xh-p2) and edit the _WC Blocks features merged in WC core X.Y_ page corresponding to the correct release (create it and add it to the list if it doesn't exist yet).
- Edit that page and write all highlights from the release you just made which will be available in WC core. Skip all features which are only available in the feature plugin. Make the text user-friendly, as it will be part of a public post when WC core is released (you can use what you wrote in the release announcement in the step above).
- If you are doing a release that gets merged into WC core:
- Go to its Release Thread and search the _Feature Highlights_ comment (example: p6q8Tx-2gl-p2).
- Edit the linked draft post and copy and paste all highlights from the _WC Blocks features merged in WC core X.Y_ page.
- Leave a comment under the _Feature Highlights_ comment in the release thread mentioning that you updated the draft with the features included in WC Blocks X.Y.
- [ ] Announce the release internally (`#woo-announcements` slack).
- [ ] Update user-facing documentation as needed. When the plugin is released, ensure user-facing documentation is kept up to date with new blocks and compatibility information. The dev team should update documents in collaboration with support team and WooCommerce docs guild. In particular, please review and update as needed:
- Are there any new blocks in this release? Ensure they have adequate user documentation.
- Ensure any major improvements or changes are documented.
- [ ] Update minimum supported versions (WordPress, WooCommerce Core) and other requirements where necessary, including:
- [WCCOM product page](https://woo.com/customize/)
- [WooCommerce blocks main documentation page](https://woo.com/document/woocommerce-blocks/)
- [ ] Go through the description of the release pull request and edit it to update all the sections and checklist instructions there.
- [ ] Close this PR.

View File

@ -1,40 +0,0 @@
# Release Pull Request
This is the release pull request for WooCommerce Blocks plugin `{{version}}`.
## Changelog
---
```md
{{changelog}}
```
---
## Communication
### Prepared Updates
Please leave a comment on this PR with links to the following:
- [ ] Release announcement (announcement post on developer.woo.com published after release).
{{#if devNoteItems}}
**Developer Notes** - The following issues require developer notes in the release post:
{{devNoteItems}}
{{/if}}
- [ ] Happiness engineering or Happiness/Support (if special instructions needed).
- [ ] Relevant developer documentation (if applicable).
## Quality
> This section is for things related to quality around the release.
- [ ] Testing Instructions are included in this PR
- [ ] Any performance impacts are documented.
---

View File

@ -1,36 +0,0 @@
name: Add Community Label
on:
pull_request_target:
types: [opened]
issues:
types: [opened]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
permissions: {}
jobs:
verify:
name: Verify and add label
runs-on: ubuntu-20.04
permissions:
contents: read
pull-requests: write
issues: write
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65
- name: npm install
run: npm install -D
- name: Check if user is a community contributor
id: check
run: node .github/workflows/scripts/is-community-contributor.js
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

View File

@ -1,64 +0,0 @@
name: Generate ZIP file
on: [pull_request]
jobs:
generate-zip-file:
if: ${{ !contains(github.event.pull_request.labels.*.name, 'skip-zip') }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cache node_modules
id: cache-node-modules
uses: actions/cache@v3
env:
cache-name: cache-node-modules
with:
path: node_modules
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
- name: Setup node version and npm cache
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: 'npm'
- name: Install Node dependencies
if: steps.cache-node-modules.outputs.cache-hit != 'true'
run: npm ci --no-optional
- name: Generate ZIP file
run: npm run package-plugin:deploy
- name: Create temp folder
run: mkdir wc-blocks-pr-release__temp
- name: Rename and move ZIP file
run: mv woocommerce-gutenberg-products-block.zip wc-blocks-pr-release__temp/woocommerce-gutenberg-products-block-${{ github.event.pull_request.number }}.zip
- name: Transfer ZIP file via SFTP
uses: AbleLincoln/push-to-sftp@v2.1
with:
host: ${{ secrets.FTP_HOST }}
port: 22
username: ${{ secrets.FTP_USER }}
password: ${{ secrets.FTP_PASS }}
sourceDir: ./wc-blocks-pr-release__temp/
targetDir: ${{ secrets.FTP_DIR }}
- name: Add release ZIP URL as comment to the PR
uses: ./.github/comments-aggregator
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
section-id: release-zip-url
order: 1
content: |
The release ZIP for this PR is accessible via:
```
https://wcblocks.wpcomstaging.com/wp-content/uploads/woocommerce-gutenberg-products-block-${{ github.event.pull_request.number }}.zip
```
- name: Delete ZIP file
run: rm -rf wc-blocks-pr-release__temp

View File

@ -1,16 +0,0 @@
on:
pull_request:
types: [ closed ]
name: Merged Pull Requests
jobs:
remove_labels:
name: Remove labels
runs-on: ubuntu-latest
steps:
- uses: mondeja/remove-labels-gh-action@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
labels: |
status: ready to merge

View File

@ -1,33 +0,0 @@
name: 'Monorepo Merge Notices'
on:
pull_request_target:
types: [ 'opened' ]
issues:
types: [ 'opened' ]
jobs:
issue_block:
name: 'Block Issues & Pull Requests'
runs-on: 'ubuntu-latest'
steps:
- name: 'Add Merge Notice'
uses: 'actions/github-script@v7'
with:
script: |
github.rest.issues.createComment( {
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: 'Thank you for your interest in contributing to WooCommerce!\n\n\
WooCommerce Blocks [has been merged into the WooCommerce Monorepo](https://developer.woo.com/2023/12/01/woocommerce-blocks-merging-into-the-woocommerce-monorepo/).\n\n\
From now on, please open any issues or pull requests in the [woocommerce/woocommerce](https://github.com/woocommerce/woocommerce) repository.'
} );
- name: 'Close'
uses: 'actions/github-script@v7'
with:
script: |
github.rest.issues.update({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
state: 'closed'
});

View File

@ -1,71 +0,0 @@
name: Nightly builds
on:
schedule:
- cron: '1 0 * * *' # Run at 12:01 AM UTC.
workflow_dispatch:
env:
NODE_OPTIONS: --max-old-space-size=4096 # development build takes a lot of memory
jobs:
build:
name: Nightly builds
strategy:
fail-fast: false
matrix:
build: [trunk]
runs-on: ubuntu-20.04
steps:
- name: Checkout Code
uses: actions/checkout@v3
with:
ref: ${{ matrix.build }}
- name: Install Node
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
- name: Install Node Dependencies
run: npm ci --no-optional
- name: Build zip
run: bash bin/build-plugin-zip.sh -d
- name: Deploy nightly build
uses: WebFreak001/deploy-nightly@v2.0.0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
# 80943895 is the release ID of this nightly release https://github.com/woocommerce/woocommerce-blocks/releases/tag/nightly
upload_url: https://uploads.github.com/repos/${{ github.repository }}/releases/80943895/assets{?name,label}
release_id: 80943895
asset_path: woocommerce-gutenberg-products-block.zip
asset_name: woocommerce-blocks-${{ matrix.build }}-nightly.zip
asset_content_type: application/zip
max_releases: 1
- name: Get Date
id: date
uses: lee-dohm/calculate-dates-and-times@v1.0.2
with:
format: 'YYYY-MM-DD'
subtract: '1 day'
- name: Update release notes
uses: irongut/EditRelease@v1.2.0
with:
token: ${{ secrets.GITHUB_TOKEN }}
id: 80943895
body: "Nightly release auto generated everyday at 12:01 AM UTC. \n\n[PRs merged since last nightly build](https://github.com/woocommerce/woocommerce-blocks/pulls?q=is%3Apr+closed%3A>%3D${{ steps.date.outputs.date }}+is%3Amerged)"
spacing: 0
replacebody: true
update:
name: Update nightly tag commit ref
runs-on: ubuntu-20.04
steps:
- name: Update nightly tag
uses: richardsimko/github-tag-action@v1.0.11
with:
tag_name: nightly
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

View File

@ -1,65 +0,0 @@
name: PHP Coding Standards
on:
push:
branches:
- trunk
pull_request:
jobs:
# Runs PHP coding standards checks.
# Note: Inspired by https://github.com/WordPress/wordpress-develop/blob/master/.github/workflows/coding-standards.yml
#
# Violations are reported inline with annotations.
#
# Performs the following steps:
# - Checks out the repository.
# - Configures caching for Composer.
# - Sets up PHP.
# - Logs debug information.
# - Installs Composer dependencies (from cache if possible).
# - Logs PHP_CodeSniffer debug information.
# - Runs PHPCS on the full codebase with warnings suppressed.
# - todo: Configure Slack notifications for failing scans.
phpcs:
name: PHP coding standards
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Get Composer cache directory
id: composer-cache
run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
- name: Set up Composer caching
uses: actions/cache@v3
env:
cache-name: cache-composer-dependencies
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.0'
coverage: none
tools: composer, cs2pr
- name: Log debug information
run: |
php --version
composer --version
- name: Install Composer dependencies
run: |
composer install --prefer-dist --no-suggest --no-progress --no-ansi --no-interaction
echo "${PWD}/vendor/bin" >> $GITHUB_PATH
- name: Log PHPCS debug information
run: phpcs -i
- name: Run PHPCS on all changed files
run: |
phpcs ./src -q --report=checkstyle | cs2pr

View File

@ -1,174 +0,0 @@
name: E2E tests
on:
push:
branches: [trunk]
pull_request:
jobs:
JSE2EWithGutenberg:
if: ${{ false }} # disable until we've fixed failing tests.
strategy:
fail-fast: false
matrix:
part: [1, 2, 3, 4, 5]
name: JavaScript E2E Tests (WP latest with Gutenberg plugin)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Cache node_modules
id: cache-node-modules
uses: actions/cache@v3
env:
cache-name: cache-node-modules
with:
path: node_modules
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
- name: Setup node version and npm cache
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: 'npm'
- name: Install Node Dependencies
if: steps.cache-node-modules.outputs.cache-hit != 'true'
run: npm ci --no-optional
- name: Build Assets
run: FORCE_REDUCED_MOTION=true npm run build
- name: blocks.ini setup
run: |
echo -e 'woocommerce_blocks_phase = 3\nwoocommerce_blocks_env = tests' > blocks.ini
- name: Get Composer Cache Directory
id: composer-cache
run: |
echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
- uses: actions/cache@v3
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.0'
coverage: none
tools: composer
- name: Composer install
run: |
composer install
- name: E2E Tests (WP latest with Gutenberg plugin)
env:
WOOCOMMERCE_BLOCKS_PHASE: 3
run: |
node ./bin/wp-env-with-gutenberg.js
npm run wp-env start
npm run wp-env:config && npx cross-env NODE_CONFIG_DIR=tests/e2e-jest/config wp-scripts test-e2e --config tests/e2e-jest/config/jest.config.js --listTests > ~/.jest-e2e-tests
npx cross-env JEST_PUPPETEER_CONFIG=tests/e2e-jest/config/jest-puppeteer.config.js cross-env NODE_CONFIG_DIR=tests/e2e-jest/config wp-scripts test-e2e --config tests/e2e-jest/config/jest.config.js --runInBand --runTestsByPath $( awk 'NR % 5 == ${{ matrix.part }} - 1' < ~/.jest-e2e-tests )
- name: Upload artifacts on failure
if: ${{ failure() }}
uses: actions/upload-artifact@v3.1.2
with:
name: e2e-with-gutenberg-test-report-${{matrix.part}}
path: reports/e2e
- name: Archive flaky tests report
uses: actions/upload-artifact@v3.1.2
if: always()
with:
name: flaky-tests-report-${{ matrix.part }}
path: flaky-tests
if-no-files-found: ignore
JSE2ETests:
name: JavaScript E2E Tests (latest)
strategy:
fail-fast: false
matrix:
part: [1, 2, 3, 4, 5]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Cache node_modules
id: cache-node-modules
uses: actions/cache@v3
env:
cache-name: cache-node-modules
with:
path: node_modules
key: ${{ runner.os }}-modified-build-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-modified-build-${{ env.cache-name }}-
${{ runner.os }}-modified-build-
${{ runner.os }}-modified-
- name: Setup node version and npm cache
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: 'npm'
- name: Install Node dependencies
if: steps.cache-node-modules.outputs.cache-hit != 'true'
run: npm install --no-optional --no-audit
- name: Build Assets
run: FORCE_REDUCED_MOTION=true npm run build
- name: blocks.ini setup
run: |
echo -e 'woocommerce_blocks_phase = 3\nwoocommerce_blocks_env = tests' > blocks.ini
- name: Get Composer Cache Directory
id: composer-cache
run: |
echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
- uses: actions/cache@v3
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.0'
coverage: none
tools: composer
- name: Composer install
run: |
composer install
- name: E2E Tests (WP latest)
env:
WOOCOMMERCE_BLOCKS_PHASE: 3
run: |
node ./bin/wp-env-with-wp-641.js
npm run wp-env start
npm run wp-env:config && npx cross-env NODE_CONFIG_DIR=tests/e2e-jest/config wp-scripts test-e2e --config tests/e2e-jest/config/jest.config.js --listTests > ~/.jest-e2e-tests
npx cross-env JEST_PUPPETEER_CONFIG=tests/e2e-jest/config/jest-puppeteer.config.js cross-env NODE_CONFIG_DIR=tests/e2e-jest/config wp-scripts test-e2e --config tests/e2e-jest/config/jest.config.js --runInBand --runTestsByPath $( awk 'NR % 5 == ${{ matrix.part }} - 1' < ~/.jest-e2e-tests ) --listTests
npx cross-env JEST_PUPPETEER_CONFIG=tests/e2e-jest/config/jest-puppeteer.config.js cross-env NODE_CONFIG_DIR=tests/e2e-jest/config wp-scripts test-e2e --config tests/e2e-jest/config/jest.config.js --runInBand --runTestsByPath $( awk 'NR % 5 == ${{ matrix.part }} - 1' < ~/.jest-e2e-tests )
- name: Upload artifacts on failure
if: ${{ failure() }}
uses: actions/upload-artifact@v3.1.2
with:
name: e2e-test-report-${{matrix.part}}
path: reports/e2e
- name: Archive flaky tests report
uses: actions/upload-artifact@v3.1.2 # v2.2.2
if: always()
with:
name: flaky-tests-report-${{ matrix.part }}
path: flaky-tests
if-no-files-found: ignore

View File

@ -1,24 +0,0 @@
name: Pull Request Label Validation
on:
pull_request:
branches:
- trunk
types:
- labeled
- unlabeled
- opened
- reopened
- synchronize
- edited
env:
LABELS: ${{ join( github.event.pull_request.labels.*.name, ' ' ) }}
jobs:
check-type-label:
name: Check [Type] Label
runs-on: ubuntu-latest
steps:
- if: contains( env.LABELS, 'type' ) == false && contains( env.LABELS, 'skip-changelog' ) == false
run: exit 1

View File

@ -1,35 +0,0 @@
name: Release Pull Request Automation
# Controls when the action will run. Triggers the workflow on create branch or tag
# events but only acts on branch create.
on:
create:
jobs:
release-pull-request-automation:
if: ${{ github.event.ref_type == 'branch' && contains( github.ref, 'release/' ) }}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
runs-on: ubuntu-latest
steps:
- uses: act10ns/slack@v2
with:
status: starting
if: ${{ always() }}
- name: Checkout code
uses: actions/checkout@v3
- name: Create changeset for pull request
run: |
git config user.name github-actions
git config user.email github-actions@github.com
git commit -m 'Empty commit for release pull request' --allow-empty
git push
- name: Create Release Pull Request
uses: woocommerce/automations@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
automations: release
- uses: act10ns/slack@v2
with:
status: ${{ job.status }}
steps: ${{ toJson(steps) }}
if: ${{ always() }}

View File

@ -1,128 +0,0 @@
name: Unit Tests
# Since Unit Tests are required to pass for each PR,
# we cannot disable them for documentation-only changes.
on:
pull_request:
push:
branches: [trunk]
# Allow manually triggering the workflow.
workflow_dispatch:
# Cancels all previous workflow runs for pull requests that have not completed.
concurrency:
# The concurrency group contains the workflow name and the branch name for pull requests
# or the commit hash for any other events.
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && github.head_ref || github.sha }}
cancel-in-progress: true
jobs:
JSUnitTests:
name: JS Unit Tests
runs-on: ubuntu-latest
if: ${{ github.repository == 'WooCommerce/WooCommerce-Blocks' || github.event_name == 'pull_request' }}
strategy:
fail-fast: false
steps:
- uses: actions/checkout@v3
- name: Use desired version of NodeJS
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: npm
- name: Npm install and build
run: |
npm ci --no-optional
FORCE_REDUCED_MOTION=true npm run build
- name: blocks.ini setup
run: echo -e 'woocommerce_blocks_phase = 3\nwoocommerce_blocks_env = test' > blocks.ini
- name: Run JavaScript Unit tests
run: npm run test
PHPUnitTests:
name: PHP ${{ matrix.php }}
runs-on: ubuntu-latest
timeout-minutes: 20
if: ${{ github.repository == 'WooCommerce/WooCommerce-Blocks' || github.event_name == 'pull_request' }}
strategy:
fail-fast: true
matrix:
php:
- '7.4'
- '8.0'
- '8.1'
- '8.2'
env:
WP_ENV_PHP_VERSION: ${{ matrix.php }}
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version-file: '.nvmrc'
cache: npm
##
# This allows Composer dependencies to be installed using a single step.
#
# Since the tests are currently run within the Docker containers where the PHP version varies,
# the same PHP version needs to be configured for the action runner machine so that the correct
# dependency versions are installed and cached.
##
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '${{ matrix.php }}'
ini-file: development
coverage: none
# Ensure that Composer installs the correct versions of packages.
- name: Override PHP version in composer.json
run: |
composer config platform.php ${{ matrix.php }}
composer update
- name: Install npm dependencies
run: |
npm ci
npm run build
- name: Docker debug information
run: |
docker -v
docker-compose -v
- name: General debug information
run: |
npm --version
node --version
curl --version
git --version
svn --version
locale -a
- name: Start Docker environment
run: npm run wp-env start --update
- name: Log running Docker containers
run: docker ps -a
- name: Docker container debug information
run: |
npm run wp-env run tests-mysql mysql -- --version
npm run wp-env run tests-wordpress php -- --version
npm run wp-env run tests-wordpress php -- -m
npm run wp-env run tests-wordpress php -- -i
npm run wp-env run tests-wordpress locale -- -a
- name: Run PHPUnit tests
run: npm run test:php

View File

@ -1,40 +0,0 @@
name: Deploy to WordPress.org
on:
release:
types: [released]
jobs:
tag:
name: New Release
runs-on: ubuntu-latest
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
steps:
- uses: act10ns/slack@v2
with:
status: starting
if: ${{ always() }}
- name: Checkout code
uses: actions/checkout@v3
- name: WordPress Plugin Deploy
id: deploy
uses: 10up/action-wordpress-plugin-deploy@stable
with:
generate-zip: true
env:
SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
SLUG: woo-gutenberg-products-block
- name: Upload release asset
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ github.event.release.upload_url }}
asset_path: ${{github.workspace}}/woo-gutenberg-products-block.zip
asset_name: woo-gutenberg-products-block.zip
asset_content_type: application/zip
- uses: act10ns/slack@v2
with:
status: ${{ job.status }}
steps: ${{ toJson(steps) }}
if: ${{ always() }}

View File

@ -0,0 +1,4 @@
Significance: patch
Type: dev
clear out unneeded github files from block folder

View File

@ -0,0 +1,4 @@
Significance: patch
Type: dev
clear out unneeded github files from block folder