* except that they are always enabled. These methods should be used instead of Java assertions
 * whenever there is a chance the check may fail "in real life". Example:
 *
 * <pre>{@code
 * Bill bill = remoteService.getLastUnpaidBill();
 *
 * // In case bug 12345 happens again we'd rather just die
 * Verify.verify(bill.status() == Status.UNPAID,

		want            string
		wantErrStr      string
		k8sMinorVersion string
	}{
		{
			testName:   "fail to create remote secret token",
			objs:       []runtime.Object{kubeSystemNamespace, sa, saSecretMissingToken},
			wantErrStr: `no "token" data found`,
		},
		{
			testName:          "fail to encode secret",
			objs:              []runtime.Object{kubeSystemNamespace, sa, saSecret},

  fun run() {
    // The typical PKCS11 slot, may vary with different hardware.
    val slot = 0

    val config = "--name=OpenSC\nlibrary=/Library/OpenSC/lib/opensc-pkcs11.so\nslot=$slot\n"

    // May fail with ProviderException with root cause like
    // sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SLOT_ID_INVALID
    val pkcs11 = Security.getProvider("SunPKCS11").configure(config)
    Security.addProvider(pkcs11)

    stack.addTearDown(tearDownTwo);

    assertEquals(false, tearDownOne.ran);
    assertEquals(false, tearDownTwo.ran);

    try {
      stack.runTearDown();
      fail("runTearDown should have thrown an exception");
    } catch (ClusterException expected) {
      assertThat(expected).hasCauseThat().hasMessageThat().isEqualTo("two");
    } catch (RuntimeException e) {

    assertThatFutureFailsWithException(closingFuture.statusFuture());
    ValueAndCloser<?> valueAndCloser = finishToValueAndCloser(closingFuture);
    try {
      valueAndCloser.get();
      fail();
    } catch (ExecutionException expected) {
      assertThat(expected).hasCauseThat().isSameInstanceAs(exception);
    }
    valueAndCloser.closeAsync();
  }

  @Override

   *
   * <p>Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally
   * speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent
   * modification. Fail-fast iterators throw {@code ConcurrentModificationException} on a
   * best-effort basis. Therefore, it would be wrong to write a program that depended on this

      fail("Expected IllegalArgumentException");
    } catch (IllegalArgumentException expected) {
    }

    try {
      multiset.add(entry.getElement());
      fail("Expected IllegalArgumentException");
    } catch (IllegalArgumentException expected) {
    }

    try {
      multiset.addAll(singletonList(entry.getElement()));
      fail("Expected IllegalArgumentException");

    assertEquals(-1, matcher.indexIn(""));
    assertEquals(-1, matcher.indexIn("", 0));
    try {
      matcher.indexIn("", 1);
      fail();
    } catch (IndexOutOfBoundsException expected) {
    }
    try {
      matcher.indexIn("", -1);
      fail();
    } catch (IndexOutOfBoundsException expected) {
    }
    assertEquals(-1, matcher.lastIndexIn(""));
    assertFalse(matcher.matchesAnyOf(""));

				t.Errorf("Test %d: %s: Expected to fail with <ERROR> \"%s\", but passed instead", i+1, instanceType, testCase.err.Error())
			}
			// Failed as expected, but does it fail for the expected reason.
			if err != nil && !testCase.shouldPass {
				if !strings.Contains(err.Error(), testCase.err.Error()) {

      # required to fetch internal or private CodeQL packs
      packages: read

      # only required for workflows in private repositories
      actions: read
      contents: read

    strategy:
      fail-fast: false
      matrix:
        include:
        - language: java-kotlin
          build-mode: none # This mode only analyzes Java. Set this to 'autobuild' or 'manual' to analyze Kotlin too.