Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ResponseOps] allow Slack API URL to be overridden for functional tests #1

Open
wants to merge 1 commit into
base: 154359-create-slac-web-api-connector
Choose a base branch
from

Conversation

pmuellr
Copy link
Owner

@pmuellr pmuellr commented Apr 21, 2023

Not intended to be merged directly

Summary

This is part of the effort to get the Slack API functional tests going. For that, we need to allow
the Slack API URL, which before was hard-coded, to be updated so that it can be set to point to
the Slack API simulator server we will eventually create.

I first tried making this a config setting for stack_connectors - but I could see that was going to be messy - we'd have to know the port of the server before actually starting the functional test server, which starts the server simulators. But ... the port may end up being determined dynamically, so ... there's no way to know it.

I ended up making the URL updateable via a new function, removed the existing const of the value, and changed those references to use the new function which returns the updateable value - internalGetSlackApiURL().

All we should have to do to start using this, is call the internalSetSlackApiURL() function with the URL of the slack API simulator, once we know it. I didn't expose the function any further up the directory tree, as I wasn't sure we would need to. Guessing we may, as we will have to call this from the x-pack/test modules that create the slack API simulator.

pmuellr pushed a commit that referenced this pull request Dec 12, 2023
## Summary

### This PR enables user roles testing in FTR

We use SAML authentication to get session cookie for user with the
specific role. The cookie is cached on FTR service side so we only make
SAML auth one time per user within FTR config run. For Kibana CI service
relies on changes coming in elastic#170852

In order to run FTR tests locally against existing MKI project:
- add `.ftr/role_users.json` in Kibana root dir
```
{
  "viewer": {
    "email": "...",
    "password": "..."
  },
  "developer": {
    "email": "...",
    "password": "..."
  }
}

```
- set Cloud hostname (!not project hostname!) with TEST_CLOUD_HOST_NAME,
e.g.
`export TEST_CLOUD_HOST_NAME=console.qa.cld.elstc.co`


### How to use:

- functional tests:
```
const svlCommonPage = getPageObject('svlCommonPage');

before(async () => {
  // login with Viewer role  
  await svlCommonPage.loginWithRole('viewer');
  // you are logged in in browser and on project home page, start the test 
});

it('has project header', async () => {
  await svlCommonPage.assertProjectHeaderExists();
});
```

- API integration tests:
```
const svlUserManager = getService('svlUserManager');
const supertestWithoutAuth = getService('supertestWithoutAuth');
let credentials: { Cookie: string };

before(async () => {
  // get auth header for Viewer role  
 credentials = await svlUserManager.getApiCredentialsForRole('viewer');
});

it('returns full status payload for authenticated request', async () => {
    const { body } = await supertestWithoutAuth
    .get('/api/status')
    .set(credentials)
    .set('kbn-xsrf', 'kibana');

    expect(body.name).to.be.a('string');
    expect(body.uuid).to.be.a('string');
    expect(body.version.number).to.be.a('string');
});
```

Flaky-test-runner: 

#1
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4081
elastic#2
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4114

---------

Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant