Bumps the npm_and_yarn group with 1 update in the / directory:
[micromatch](https://github.com/micromatch/micromatch).
Updates `micromatch` from 4.0.7 to 4.0.8
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/micromatch/micromatch/releases">micromatch's
releases</a>.</em></p>
<blockquote>
<h2>4.0.8</h2>
<p>Ultimate release that fixes both CVE-2024-4067 and CVE-2024-4068. We
consider the issues low-priority, so even if you see automated scanners
saying otherwise, don't be scared.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/micromatch/micromatch/blob/master/CHANGELOG.md">micromatch's
changelog</a>.</em></p>
<blockquote>
<h2>[4.0.8] - 2024-08-22</h2>
<ul>
<li>backported CVE-2024-4067 fix (from v4.0.6) over to 4.x branch</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="8bd704ec0d"><code>8bd704e</code></a>
4.0.8</li>
<li><a
href="a0e68416a4"><code>a0e6841</code></a>
run verb to generate README documentation</li>
<li><a
href="4ec288484f"><code>4ec2884</code></a>
Merge branch 'v4' into hauserkristof-feature/v4.0.8</li>
<li><a
href="03aa805217"><code>03aa805</code></a>
Merge pull request <a
href="https://redirect.github.com/micromatch/micromatch/issues/266">#266</a>
from hauserkristof/feature/v4.0.8</li>
<li><a
href="814f5f70ef"><code>814f5f7</code></a>
lint</li>
<li><a
href="67fcce6a10"><code>67fcce6</code></a>
fix: CHANGELOG about braces & CVE-2024-4068, v4.0.5</li>
<li><a
href="113f2e3fa7"><code>113f2e3</code></a>
fix: CVE numbers in CHANGELOG</li>
<li><a
href="d9dbd9a266"><code>d9dbd9a</code></a>
feat: updated CHANGELOG</li>
<li><a
href="2ab13157f4"><code>2ab1315</code></a>
fix: use actions/setup-node@v4</li>
<li><a
href="1406ea38f3"><code>1406ea3</code></a>
feat: rework test to work on macos with node 10,12 and 14</li>
<li>Additional commits viewable in <a
href="https://github.com/micromatch/micromatch/compare/4.0.7...4.0.8">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/Qiskit/documentation/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Part of https://github.com/Qiskit/documentation/issues/1870. We'll set
up redirects in closed source from `qiskit-transpiler-service/*` to
`qiskit-ibm-transpiler/*`.
We don't yet generate `qiskit-ibm-transpiler` version 0.5 because that
is going to require a new set of more specific redirects, as the page
names will change from `qiskit_transpiler_service.Foo` to
`qiskit_ibm_transpiler.Foo`. That'll be done in a follow up after this
initial migration is complete.
We were being inconsistent with calling Runtime "Qiskit Runtime IBM
Client" but "Qiskit IBM Runtime REST API". We also don't use IBM with
"Qiskit Transpiler Service Client" and "Qiskit SDK". So, `@jyu00` and
`@javabster` proposed that we simplify to remove the redundant IBM.
This PR updates the left page titles we use. A closed source PR will
update the top dropdown.
We don't update the index pages for Runtime API docs because those are
auto-generated.
Suggestion to make the sentence clearer - use this, from Marco:
> The scheduler's default behavior is to select the next job by first
identifying the group that has used the least amount of their allocation
within the current scheduling window. If the selected group has more
than one project, and both have jobs waiting to be executed, then the
scheduler identifies the project that has used the least of their
allocation within the scheduling window. Finally, if the selected
project has submitted more than one job, the scheduler will select the
oldest job first.
Also adds appropriate trademark to a recent appearance of "IBM" on the
page
An action recently executed the notebooks in this repo. This PR updates
all notebooks that ran successfully with the new cell outputs.
> [!NOTE]
> This pull request was created by a GitHub action.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Before, we never copied images for the release notes file to the
historical API folder. For example, if we had the file
`public/images/qiskit/release_notes_0_0.png`, we would not copy it over
to `public/images/qiskit/1.1/release_notes_0_0.png` when we convert 1.1
from the latest release to instead be a historical release stored at
`qiskit/1.1`.
That is the right behavior for Runtime and Provider, because they only
have a single `release_notes.mdx` file. However, it does not work
correctly with Qiskit, which has one release note file per release.
This PR differentiates between the two use cases. It keeps things
generic by using our `Pkg.hasSeparateReleaseNotes` mechanism.
Will get more information from @samantha Barron, but I'm adding some
information here as a placeholder.
---------
Co-authored-by: Abby Mitchell <23662430+javabster@users.noreply.github.com>
Co-authored-by: ABBY CROSS <across@us.ibm.com>
Co-authored-by: Samuele Ferracin <sam.ferracin@ibm.com>
In Qiskit 1.2.0 a new env variable was added to control the threading
behavior of the routing and layout passes in the preset pass managers.
You can see the details of this new option in the 1.2.0 release notes or
in the PR Qiskit/qiskit#12780. This commit adds the documentation for
this feature to the local configuration guide.
---------
Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
Co-authored-by: abbycross <across@us.ibm.com>
The artifact upload was failing because `path` was set to the empty
string. It's fine to give an invalid file path like `no-changes`, so
long as we give something. The action will warn but not fail in this
case.
Closes https://github.com/Qiskit/documentation/issues/1826.
## Switches to Python 3.11
Qiskit Serverless requires Python 3.11+ now, even though Qiskit SDK
still supports 3.9 and 3.10. While I'm talking to the Serverless team,
it seems very unlikely they are going to change their mind on this due
to their own constraints.
Unfortunately, this means that we need to always use Python 3.11 with
our repository so that we can install serverless for the files that use
it. Our other alternative is to stop testing the files with Serverless,
but that seems even worse.
The risk with using 3.11 in CI rather than 3.9 is that we may use syntax
not in Python 3.9 and 3.10. However, given the actual history of our
docs, this seems unlikely: we don't use new Python syntax like type
hints. If we do use Python 3.11-syntax, it's not the end of the world.
## Tests all notebooks on changes to requirements.txt
This was an oversight that we would not test the notebooks when changing
requirements.txt. So, we merged a change that worked locally but broke
CI. Now, we test all notebooks when the nb-tester program and config
changes.
## Also upgrades Runtime
This is necessary to make Serverless happy. According to
https://docs.quantum.ibm.com/api/qiskit-ibm-runtime/release-notes#0270-2024-08-08,
there are no breaking changes. CI also shows everything passes.
This means that we now have our first historical version of
qiskit-transpiler-service: 0.3. So, we need to update
`checkInternalLinks.ts` to start checking historical versions.
We don't yet add a dev version because it's annoying to maintain and the
users are too few for now.
#1799 says you cannot change a session's max TTL. What it really meant
to say was you cannot change the _system defined_ max TTL. You can,
however, set a limit that's lower than the system ceiling.
Thanks @beckykd for spotting this!
---------
Co-authored-by: Rebecca Dimock <66339736+beckykd@users.noreply.github.com>
This is a proposal to address
https://github.com/Qiskit/documentation/issues/1696, which doesn't
correspond with my original reply.
While updating to the changes in ISA handling doesn't seem to
complicated, I realized that updating the guide to use Primitives V2
seems very strange to me (because that is not how the migration was done
at the time). The current guide is a (in my opinion, valid) reflection
of what the motivations were with primitives V1, and the reason why it
was appreciated was because it reflected well the evolution of the code.
I also think that it is commonly understood that migration guides are
written at a specific point in time, and may require "chaining" with a
further migration guide to reach the current state of the package. So,
instead of migrating everything to V2, I propose adding a warning at the
beginning of the guide pointing to the V1 to V2 migration guide.
Once again, this is just a proposal, and I am happy to rethink this.
---------
Co-authored-by: Rebecca Dimock <beckyd@us.ibm.com>
This PR is a proposal to partially address
https://github.com/Qiskit/documentation/issues/846. The issue was
written pre-backend primitives V2, when there were more differences in
the interface (*) between runtime and backend primitives, so proposing a
separate guide seemed reasonable at the time. Now (V2), I think the
differences are small enough to keep the backend primitives section as
an appendix to the get-started page, where I just added the usual V1-V2
tabs and a section at the end explaining differences.
This is just a rough proposal and it has been a while since I've written
a guide, so feel free to edit it to fit the style/conventions that are
used now.
---
(*) Backend primitives handled different kinds of pass managers to run
before and after parameter binding, but V2 primitives no longer do any
transpilation, so the way you run and configure backend and runtime
primitives is almost the same. I didn't add the V1 explanation for the
interface differences because V1 primitives are deprecated since qiskit
1.2 (released yesterday) and I think it would clutter the page and
confuse users to add an explanation of how they worked now.
---------
Co-authored-by: Rebecca Dimock <beckyd@us.ibm.com>
I recently synced these files with closed source, so I sorted them
beforehand to be easier to work with.
I did this by running:
```
sort -o scripts/config/cspell/dictionaries/qiskit.txt scripts/config/cspell/dictionaries/qiskit.txt
sort -o scripts/config/cspell/dictionaries/people.txt scripts/config/cspell/dictionaries/people.txt
```
dependabot[bot]