Merge branch 'main' into 4354_msts-doc

docs/source/release_notes.rst

@@ -7,6 +7,7 @@ Release Notes
         * Pinned networkx version below 3.2 for Python version compatibility :pr:`4351`
     * Documentation Changes
         * Added multiseries time series section to user guide in documentation :pr:`4355`
+      * Updated release guide to include an FAQ section about fixing github actions :pr:`4346`
     * Testing Changes
 
 .. warning::

evalml/tests/dependency_update_check/latest_dependency_versions.txt

@@ -21,7 +21,7 @@ nlp-primitives==2.11.0
 numpy==1.24.4
 packaging==23.2
 pandas==2.0.3
-plotly==5.17.0
+plotly==5.18.0
 pmdarima==2.0.4
 pyzmq==25.1.1
 scikit-learn==1.3.2

release.md

@@ -12,7 +12,8 @@ Before starting the release process, verify the following:
 
 EvalML uses [semantic versioning](https://semver.org/). Every release has a major, minor and patch version number, and are displayed like so: `<majorVersion>.<minorVersion>.<patchVersion>`.
 
-If you'd like to create a development release, which won't be deployed to pypi and conda and marked as a generally-available production release, please add a "dev" prefix to the patch version, i.e. `X.X.devX`. Note this claims the patch number--if the previous release was `0.12.0`, a subsequent dev release would be `0.12.dev1`, and the following release would be `0.12.2`, *not* `0.12.1`. Development releases deploy to [test.pypi.org](https://test.pypi.org/project/evalml/) instead of to [pypi.org](https://pypi.org/project/evalml).
+If you'd like to create a `development` release, which won't be deployed to pypi and conda and marked as a generally-available production release, please add a "dev" prefix to the patch version, i.e. `X.X.devX`. 
+* Note: this claims the patch number--if the previous release was `0.12.0`, a subsequent dev release would be `0.12.dev1`, and the following release would be `0.12.2`, *not* `0.12.1`. Development releases deploy to [test.pypi.org](https://test.pypi.org/project/evalml/) instead of to [pypi.org](https://pypi.org/project/evalml).
 
 ## 1. Freeze `main` and run perf tests
 After confirming the release is ready to go in step 0, we'll freeze the `main` branch and kick off the release performance tests.
@@ -23,10 +24,11 @@ Once a perf test document has been reviewed and approved by the team, we'll move
 Please use the following pattern for the release PR branch name: "release_vX.X.X". Doing so will bypass our release notes checkin test which requires all other PRs to add a release note entry.
 
 Create a release PR with the following changes:
-* Update `setup.py` and `evalml/__init__.py` to bump `__version__` to the new version.
+* Update `evalml/__init__.py` to bump `__version__` to the new version.
 * Move all entries in `docs/source/release_notes.rst` currently listed under `**Future Releases**` to be under a new heading with the version number and release date.
 * Make sure `**Future Releases**` is empty except for the sub-headings, so it's ready for new entries.
-* Populate the release PR body with a copy of this release's release notes, reformatted to [GitHub markdown](https://guides.github.com/features/mastering-markdown/). You'll reuse this text in step 2. You can generate the markdown by running `tools/format_release_notes.sh` locally.
+* Populate the release PR body with a copy of this release's release notes, reformatted to [GitHub markdown](https://guides.github.com/features/mastering-markdown/). You'll reuse this text in step 2. 
+  * You can generate the markdown by running `tools/format_release_notes.sh` locally.
 * Confirm that all release items are in the release notes under the correct header, and that no extra items are listed. You may have to do an "empty cache and hard reset" in your browser to see updates.
 
 An example can be found here: https://github.com/alteryx/evalml/pull/163
@@ -54,6 +56,8 @@ Save the release as a draft and make sure it looks correct. You could start the
 
 When it's ready to go, hit "Publish release." This will create a "vX.X.X" tag for the release, which tells ReadtheDocs to build and update the "stable" version. This will also deploy the release [to pypi](https://pypi.org/project/evalml/), making it publicly accessible!
 
+The release to pypi should be pretty fast, so make sure to keep an eye on the pypi [website](https://pypi.org/project/evalml/) to see that evalml is updated. If pypi isn't updating, check one of the recent Github actions (the action should be called `release` and its name should be the latest release version e.g. `v0.81.0`) to make sure it isn't failing.
+
 ## 4. Make Documentation Public for Release Version
 Creating the GitHub release should have updated the default `stable` docs branch to point at the new version. You'll now need to activate the new release version on ReadtheDocs so its publicly visible in the list of versions. This is important so users can view old documentation versions which match their installed version.
 
@@ -87,7 +91,7 @@ A couple of hours after you publish the GitHub release, a bot will open a PR to
 bumps the recipe to use the latest version of the package.
 In order to publish our latest conda package, we need to make some changes to the bot's PR and merge it.
 
-The bot's PR will will remove the quotes around the version tag in the recipe.
+The bot's PR will remove the quotes around the version tag in the recipe.
 Removing these quotes will break our `build_conda_pkg` CI job so add them back in and push your changes to the bot's PR. 
 For example, lines 3-5 of the [recipe](https://github.com/conda-forge/evalml-core-feedstock/blob/master/recipe/meta.yaml) should look like the following:
 ```yaml
@@ -100,8 +104,9 @@ For help on how to push changes to the bot's PR please read this [document.](htt
 You may need to make other changes to the bot's PR. For example, there is a CI check called "Check conda versions/check_versions" that
 verifies whether the dependency versions of the conda update PR match the versions of the recipe used in
 `build_conda_pkg` (located in `.github/meta.yaml`). If the check is red, modify the dependencies so they match those in `.github/meta.yaml`.
+* An example of these dependency updates would be this [PR](https://github.com/conda-forge/evalml-core-feedstock/pull/147/files)
 
-After you make the necessary changes and merge the PR, our latest package will be deployed to conda-forge! To verify, run this in a fresh conda environment:
+After you make the necessary changes, merge the PR, and it passed the checks in main, our latest package will be deployed to conda-forge! To verify, check the [conda website](https://anaconda.org/conda-forge/evalml) to see if it says the latest version and run the following in a fresh conda environment:
 
 ```shell
 conda install -c conda-forge evalml
@@ -121,3 +126,16 @@ Per the instructions [here](https://conda-forge.org/docs/maintainer/updating_pkg
     - Select *Bot commands* and put the following title (change `username`): `@conda-forge-admin, please add user @username`
 2. A PR will be auto-created on the repo, and will need to be merged by an existing maintainer.
 3. The new user will need to **check their email for an invite link to click**, which should be https://github.com/conda-forge
+
+## Troubleshooting failed Github actions
+
+If some Github actions are failing and they don't automatically run in the PR's automated tests, to easily test them without having to push to main:
+1. In your local branch, find the workflow file for the Github action (most likey in `.github/workflow` folder)
+2. In the `.yaml` file for the github action, change it so that on push for your local branch it runs the github actions. For example, lines 4-7 of [`build_conda_pkg.yaml`](https://github.com/alteryx/evalml/blob/main/.github/workflows/build_conda_pkg.yaml) should look like the following:
+```
+  push:
+    branches:
+      - main
+      - your_local_branch_name_here
+```
+3. Once you've troubleshooted and fixed the issue, remember to remove the line with your local branch name from the `.yaml` file.