Release 2.0.1 #677
Merged
Release 2.0.1 #677
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `$priority` parameter in the `register()` method is intended to allow for prioritizing the order in which callbacks are run, however, this priority was effectively not used, so callbacks would be run in the order different priorities were _registered_, not ordered _by_ the priorities. This commit fixes this + adds a unit test to safeguard the fix. I've elected to add the sorting to the `dispatch()` method, rather than the `register()` method for performance reasons. Sorting arrays can be expensive and this way, only the subarrays of those hooks which are actually being run will be sorted, instead of sorting the subarray every time a new callback is registered, whether the hook on which the callback is registered will be called or not. Fixes 452
Previously this codebase mostly placed the `else` (or other follow-on keyword in a multi-part control structure) on a new line, except this was not enforced leading to inconsistency across the codebase. By removing the exclusion from the PHPCS ruleset, we now enforce the follow-on keyword in a multi-part control structure to be on the same line as the closing brace of the preceding control structure. This is in line with both WPCS as well as PSR-12.
Remove some exclusions which have been superseded.
... by enforcing a blank line after control structures.
Removes various bits and pieces which are now redundant. * All the dependencies will install fine on all supported PHP versions without the need to use `ignore-platform-reqs`. * We're currently not using the `experimental` key, nor `continue-on-error`.
Discovered by and props to costdev via WordPress/wordpress-develop#2001 Co-authored-by: costdev <[email protected]>
... from `master` to `main` in line with the upstream change.
…me-test-server
The `dealerdirect/phpcodesniffer-composer-installer` Composer plugin is used to register external PHPCS standards with PHPCS. As of Composer 2.2.0, Composer plugins need to be explicitly allowed to run. This adds the necessary configuration for that. Refs: * https://blog.packagist.com/composer-2-2/#more-secure-plugin-execution
The action used to install Composer packages and handle the caching has released a new major (and some follow-up patch releases), which means, the action reference needs to be updated to benefit from it. Refs: * https://github.com/ramsey/composer-install/releases/tag/2.0.0 * https://github.com/ramsey/composer-install/releases/tag/2.0.1 * https://github.com/ramsey/composer-install/releases/tag/2.0.2
A while back the `codecov/codecov-action` released a new major. As per the release notes: > On February 1, 2022, the v1 uploader will be full sunset and no longer function. This is due to the deprecation of the underlying bash uploader. This version uses the new uploader. Considering Feb 2022 is creeping closer every day, updating seems prudent. > Multiple fields have not been transferred from the bash uploader or have been deprecated. Notably many of the `functionalities` and `gcov_` arguments have been removed. This repo does not seem to be affected by this. Refs: * https://github.com/codecov/codecov-action/releases/tag/v2.0.0 * https://github.com/codecov/codecov-action/releases/tag/v2.0.1 * https://github.com/codecov/codecov-action/releases/tag/v2.0.2 * https://github.com/codecov/codecov-action/releases/tag/v2.0.3 * https://github.com/codecov/codecov-action/releases/tag/v2.1.0
The website update workflow (re-)uses (limited) information retrieved from the original commit which triggered the workflow, such as the branch name/tag name and the committer. This type of data should always be regarded as **untrusted** input and when these `github....` variables are used directly within the `run` context, they can lead to script injection and unintended execution of commands. To mitigate the risk of these type of script injection attacks, untrusted data is first set as a step-specific interim environment variable and only after that the environment variable (not the github variables directly) is used in the `run` context. This complies with the current best practices regarding defending against these type of attacks as per January 2022. For more information, see: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
Add the checksum file for the certificate bundle to the package to allow both users of the package as well as maintainers of the package, to verify the validity of the included certificate bundle. This file should only ever be updated at the same time as the certificate bundle is being updated.
This adds a new workflow which will automatically check the cURL website for an update to the certificate bundle once a day and if an updated bundle is found, it will automatically create a pull request against the `develop` branch to update the bundle in the Requests package. The workflow will also update the certificate checksum file and verify the checksum of the downloaded certificate bundle. Notes: * A condition has been added to prevent the cron job from running on forks (to conserve resources). * The workflow uses the recommended commands for automated downloads as per the https://curl.se/docs/caextract.html page. These recommended commands do a conditional download only when a file is changed and use an `etag*.txt` file to check whether the upstream file has changed. These `etag*.txt` files don't really need to be stored in the actual repo, so they have been added to the `.gitignore` file. In the workflow, these `etag*.txt` files are stored to and restored from a workflow cache to allow for the conditional download. * While the workflow runs on a cron job and manual updating of the certificate file/checksum file should therefore never be needed, as an extra security measure, the workflow will also run whenever a PR is opened to update the certificate files or when a change to the certificate files is pushed to the `stable` or `develop` branch. Note: as PRs which are opened from within a workflow do not trigger new workflows to be run (= default behaviour for GitHub Actions), the PR potentially created by this workflow will not trigger a recursive run of this workflow. * If a PR triggers this workflow and a certificate update would be needed, a (new) PR against the original PR will be opened with the certificate update. * If the workflow is triggered via the cronjob or for a push against `stable`/`develop`, any PR which may be opened will be opened against `develop`. Fixes 635
The `src` class being tested is called `Cookie`, so the test class should be called `CookieTest`, not `CookiesTest`.
…rity-website-workflow
…ate-certificate-workflow
The GitHub API unfortunately does not have a `/tags/latest` endpoint, so to get the latest tag, we need to get all tags, then sort them based on semantic version names and then get the latest from the stack. This implements this in the script which updates the phpDocumentor configuration. The tag name is used as the API docs title in the generated docs.
This commit makes various tweaks to the website update workflow based on the experiences round the 2.0.0 release:
* Run every time a tag is pushed.
The previously included tag selection was only in place to prevent the script from running in case we'd still tag a 1.x release. As there is no intention to update the 1.x branch anymore, the tag selection can be removed.
* The `branches-ignore` addition is experimental.
It is not unusual that in the ramp up to a release, a PR from `develop` to `stable` is created before all PRs for the release have been merged.
Round the 2.0.0 release, this led to every PR merge which caused an update to the release PR to generate a new draft PR for the website update as the release contained the new workflow (which was therefore seen as "changed"), while that feature is only really intended for PRs to `develop`.
Let's see if adding `stable` to `branch-ignore` for pull requests will prevent this in the future.
the PR, but after all changes have been made).
* Also made two minor tweaks to the pull request creation inputs.
* Workflows which create PRs do not trigger any other workflows which would normally run on a PR.
This means that the `test-ghpages.yml` workflow in the `ghpages` branch is not triggered for the auto-generated PRs, while doing a test build to ensure there are no Jekyll errors when the website is deployed is kind of helpful.
As this check only involves two steps, I'm duplicating these into this workflow to ensure the ghpages build test is still executed for the auto-generated PRs.
While GH Pages does have access to the GitHub API during the site generation and deploy, the information it can access is limited. I've verified that there is no access to the tags information. This means that for those places in the site which automatically update based on information from the GH API, we need to rely on release information, i.e. the release needs to have happened already for the information to be updated correctly. This means that the merging of the GH Pages PR needs to happen after the release has been published. This is now documented as such in the release checklist. Ref: https://github.com/jekyll/github-metadata/blob/master/docs/site.github.md
Inspired by issue 220, I've:
* Verified that all hooks listed in the documentation still exist in the codebase.
* Verified the parameters for all hooks listed in the docs with the actual parameters in the hook calls in the codebase.
* Verified that all hooks in the codebase are listed in the Hooks documentation page, with the exception of the `transport.internal....` hooks.
Note:
* The hook descriptions for the added hooks can probably use further improvement. I wasn't always sure how best to describe the hook event.
* The ordering of this list looks to be a loose "requests hooks, curl hooks, fsockopen hooks and those in the order they are called" order.
With some of the additional hooks, it wasn't always clear where to place them within this loose order, so suggestions to improve the order are welcome.
Also note the the naming of the `request.progress` hook seems inconsistent. I do understand why the hook uses `request` instead of `requests`, but this may be something to revisit at a later point in time.
🔏 Update certificate bundle
Add change log entry for 2.0.1 release
|
I've not opened a new Trac ticket as the update to 2.0.0 hasn't made it into WP yet. I've mentioned the release in the already open issue, though: https://core.trac.wordpress.org/ticket/54504 |
|
Release tweet: https://twitter.com/jrf_nl/status/1490767558982742020 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR for tracking changes for the 2.0.1 release.
Target release date: Monday February 7 2022.
src/Requests.php- PR Add change log entry for 2.0.1 release #676stableand push the tag.develop!) & copy & paste the changelog to it.Make sure to copy the links to the issues and the links to the GH usernames from the bottom of the changelog!
Note: it is important to do this after the release as otherwise the information about the latest release
in the site will not be updated correctly from the GitHub API.