* fix(storage-plugin): add fs.sanitizeName for the delete request
* move empty check as well
* fix: apply formatter
* return false for exception cases
* return false for exception cases
* tweak a bit
* fix format
* feat: add IPC channels per session for drivers and plugins to communicate (fix#22206)
* lint
* export AppiumIpc
* fix test issues
* import AppiumIpc directly from basedriver
* fakedriver is used directly outside of appium so can't rely on existence of IPC
* make ipc functions async with lock and better types
* fix assignIpc types
* deduplicate session object deletion
* ipcGuard -> withIpc
* address various review comments
* lint
* address copilot and other review comments
* store only last message. change model to use subscription object and async generator
* enforce max message size in bytes
* fix tests and call the message payload 'data' for clarity
* lint
* make assignIpc optional on drivers for backwards compatibility
* add error handling in startClock since it is usually not awaited
* add docs
* remove todo comment
* apply copilot and eglitise suggestions
* add typedoc
* add error handling to onIpcInit
* apply more suggestions
* fix schema unit test
* apply more suggestions
* add links to ipc examples
* make minimum ipc message size 1 instead of 0
* ensure publisher names are friendly to consumers
* fix ipc message time unit
* use already included sizeof for objs
* just pass error obj to log
* be more typescriptey about our ipc guard
* make max obj size part of opts for appiumipc
* let unsubscribe return whether it worked
* improve ipc types and shapes
* apply master package-lock.json
* update schema config
* use javascript naming conventions
* clarify distinction between message and payload (data)
* ensure async iterator loop ends when unsubscribe is called
* ensure the right things happen when you unsubscribe
* make require ipc more ergonomic
* remove unnecessary async locks and de-asyncify methods
* simplify interface and just use subscriber/plugin names
* fix docs
* fix lint
* document isActive
* add note about topic namespace
* use sleep instead of delay
* restrict the ipc payload data type to something that can be cloned
* clarify topic namespacing recommendation
* make sure listeners and promises are cleaned up in async iterator
* clean up ipc internal names
* readonly
* address review comments
* make ipcmessage readonly
* readonly cause why not
Appium's base-driver had no dedicated ProtocolError subclass for
the W3C WebDriver 'no such shadow root' error. Every such response
from an underlying browser (the GetShadowRoot command against an
element whose shadow DOM is absent) fell through the
w3cErrorCodeMap lookup to UnknownError, making client-side error
handling (Selenium's NoSuchShadowRootException in particular)
unreachable.
Add NoSuchShadowRootError with error='no such shadow root' /
w3cStatus=404 / code=65, register it in the errors map so
errorFromW3CJsonCode returns it, and extend the existing
errors.spec table-tests to lock the new mapping.
Fixes#22209
Signed-off-by: SAY-5 <say.apm35@gmail.com>
* ci: update publish docs workflow
* use docs:publish
* Add step to fetch gh-pages before publishing docs
* ci: run after 'Appium Server Release' completion
BREAKING CHANGE: The `Promise` object in the script context now matches the global `Promise` object instead of `bluebird`. Methods specific to `bluebird` are no longer supported.
* fix(appium): fix session id handling more
* modify the comment
* Refine comments in getSessionId and the log
Updated comments for clarity and corrected typos.
* chore(base-driver): update type of express-serve-static-core
* modify
* clean up a bit
* use debug
* remove error, address possible array case
* chore: remove a line
Check if the driver proxy is active before proceeding.
In repositories indexed by CodeGraph (a `.codegraph/` directory exists at the repo root), reach for it BEFORE grep/find or reading files when you need to understand or locate code:
- **MCP tool** (when available): `codegraph_explore` answers most code questions in one call — the relevant symbols' verbatim source plus the call paths between them, including dynamic-dispatch hops grep can't follow. Name a file or symbol in the query to read its current line-numbered source. If it's listed but deferred, load it by name via tool search.
- **Shell** (always works): `codegraph explore "<symbol names or question>"` prints the same output.
If there is no `.codegraph/` directory, skip CodeGraph entirely — indexing is the user's decision.
@@ -3,7 +3,6 @@ description: Create a new bug report.
title:'🐞 bug:<title>'
labels:[Bug, Needs Triage]
body:
- type:markdown
attributes:
value:':stop_sign:_Make sure you are reporting an issue. For general questions, please use [http://discuss.appium.io](http://discuss.appium.io)._'
@@ -13,9 +12,9 @@ body:
label:Is there an existing issue for this?
description:'Please [search :mag:the issues](https://github.com/appium/appium/issues) to check if this bug has already been reported.'
options:
- label:I have searched the existing issues
required:true
- label:I have searched the existing issues
required:true
- type:input
attributes:
label:Appium Version
@@ -49,7 +48,7 @@ body:
description:|
You can retrieve the latest server/driver/plugin version number by running `npm info <package-name> version`. If you are not up to date, please try to reproduce your issue after updating all affected components.
options:
- label:I confirm the issue is still reproducible with the latest component versions
- label:I confirm the issue is still reproducible with the latest component versions
- type:textarea
attributes:
@@ -82,10 +81,10 @@ body:
:warning: _Remember to redact or remove any sensitive information!_
value:|
- Debug details (`appium --show-debug-info`):
- Last component version(s) which did _not_ exhibit the problem:
- Platform and version of device under test:
- Real device or emulator/simulator:
- Debug details (`appium --show-debug-info`):
- Last component version(s) which did _not_ exhibit the problem:
When reviewing JavaScript or TypeScript changes, check new uses of Node.js built-in APIs against the supported Node.js versions declared in package.json#engines.node. The current supported range is ^20.19.0 || ^22.12.0 || >=24.0.0.
For each new Node.js built-in API or option, verify that it exists and is stable across all supported Node.js versions. If any supported version lacks the API, only supports it experimentally, or has different behavior, leave a review comment and suggest using the existing dependency, adding a fallback, avoiding the API, or raising the engine requirement.
Example: util.styleText exists in Node.js 20.12+, but only became stable in Node.js 22.13.0 and 23.5.0. Because this repository supports Node.js 20.19.0 and 22.12.0, replacing a color library with util.styleText should be flagged unless the project explicitly accepts relying on a non-stable API for those supported versions.
# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs
name:Publish docs
on:
workflow_dispatch:
workflow_run:
workflows:['Appium Server Release']
types:
- completed
jobs:
build:
runs-on:ubuntu-latest
strategy:
matrix:
node-version:[18.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
Appium is a piece of technology, but **the core of the Appium community is the people in it**. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, gender identity and expression, sexual orientation, ability, physical appearance, body size, race, age, socioeconomic status, religion (or lack thereof), or other marginalized aspect of community members. We expect all members of the Appium community to abide by this Code of Conduct whenever interacting in Appium venues (pull requests, GitHub issues, 1-1 or group chat, meetups, conferences, etc...)
### Examples of inappropriate behavior
Because we come from a variety of backgrounds, we don't want to assume that everyone has the same assumptions about what is and isn't appropriate. Here are some examples of inappropriate behavior that are incompatible with our community's ethos:
* Spamming, trolling, intentionally disrupting conversations, or irrelevant solicitation or advertisement
* Making demeaning or discriminatory comments
* Making negative assumptions about someone's background, abilities, or intentions
* Harassing or stalking individuals (online or in person)
* Giving someone unwelcome sexual attention or making unwelcome physical contact (in the case of an IRL event)
* Sharing sexual images or using sexually explicit language
In general: treat others how you would like to be treated, were you in their place. Don't be a jerk. _Do_ ask questions. _Do_ keep conflicts productively focused on technical issues. _Do_ think before you speak; remember that what is perceived as a funny witticism in your group of friends might be hurtful or reinforce hurtful stereotypes in the context of our diverse online community. _Do_ remember that we are all people, not robots, and all equally deserving of sensitivity and respect. (If and when robots join our community, let's treat them with respect too!)
### What will organizers do about inappropriate behavior?
If we notice you doing or saying something inappropriate, an organizer will explain why it's inappropriate and ask you to stop. We won't demonize or vilify you. But please do stop the inappropriate behavior so we can get back to writing and discussing code in a safe environment. If you have philosophical disagreements about what's actually inappropriate, please take them to a separate public or private conversation with an Appium maintainer so we don't turn pull requests into an ethics debate.
If you keep doing unacceptable things, we'll likely ban you, report you to GitHub, or take other appropriate action.
### What if I see or am subject to what feels like inappropriate behavior?
Let us know! Please notify a community organizer as soon as possible. Full contact information is listed in the [Contact Info](#contact-info) section of this document. All communications will be kept strictly confidential, unless otherwise required by law. No issue will be considered too inconsequential or unimportant for us to have a conversation about.
### Contact Info
If you need to report an incident, please contact any of the following organizers directly:
* Isaac Murchie [email](mailto:isaac@saucelabs.com) [twitter](https://twitter.com/imurchie)
* Jonathan Lipps [email](mailto:jlipps@saucelabs.com) [twitter](https://twitter.com/jlipps)
### Credit, License, and Attribution
This Code of Conduct is distributed under a [Creative Commons Attribution-ShareAlike license](http://creativecommons.org/licenses/by-sa/3.0/).
It's inspired among other things by:
* [Citizen Code of Conduct](http://citizencodeofconduct.org/)
Appium is excited to participate as a [Google Summer of Code](https://summerofcode.withgoogle.com/) sponsor project. Here's a fun list of ideas that a Summer of Code student participant can use as a foundation for thinking about what to contribute to Appium!
|Idea|Description|
|----|-----------|
|Apple tvOS Support|Our users have been asking for an Appium driver for Apple tvOS apps. Is this possible? We're not entirely sure! Why not be awesome and build it?|
|Test App revamp|Appium uses a number of poorly-designed mobile applications in its own testing. We have to use a variety of apps because we need to test that Appium can automate all the various controls and platform features that mobile vendors provide. Really what we need is one cross-platform app (or one app per platform) that exhibit all and only the features we need to test. This would be a fun project to build some mobile apps used for testing and also demoing Appium at events and in training videos, etc...|
|Tooling and Performance|We haven't instrumented Appium with very many performance metrics, and don't really know if we're missing some low-hanging fruit in terms of performance. Maybe you can help us do that?|
|Babel|We have a lot of repos, and they're all on a really old version of Babel. They all need to stay in sync. How can we make this situation better, and upgrade to the latest and greatest?|
|Unity3d Driver|Historically, Appium hasn't been great at automating games. We don't have any particular support for the frameworks used to create games. Unity is a popular one, for example. What if we could write an Appium driver that talked to an embedded process in a test version of a Unity game, that allowed us to find and interact with 3d elements? It would be amazing! You can also be amazing and lead Appium into this new world.|
|Testing the Internet of Things|Appium's architecture makes it dead simple to integrate drivers for automating new technologies. What about _really_ new technologies like IoT devices? Help to redefine the semantics of the WebDriver protocol for use with IoT, and build a driver for an IoT device to prove it out.|
|Driver for X|Have an idea of something else Appium could automate that it doesn't already? Build a driver for it! This would involve some awesome Node.js code, plus whatever else is needed to integrate with the platform you have in mind.|
Hopefully this gives you some ideas of fun projects that would be substantial and long-lasting contributions to the Appium community.
* **storage-plugin:** add fs.sanitizeName for the delete request as well ([#22362](https://github.com/appium/appium/issues/22362)) ([5fee017](https://github.com/appium/appium/commit/5fee01752f2782e96fbe64fd13520b433d4a7535))
* add IPC channels per session for drivers and plugins to communicate ([#22211](https://github.com/appium/appium/issues/22211)) ([97c879c](https://github.com/appium/appium/commit/97c879cdd02e6fcccaaea45a8d1a7088bed4ae66)), closes [#22206](https://github.com/appium/appium/issues/22206)
* Limit the maximum count of topics per session and make it configurable ([#22279](https://github.com/appium/appium/issues/22279)) ([0264775](https://github.com/appium/appium/commit/0264775ecb8ecaca9dac2eae47784da02a653255))
* make assignIpc internal ([#22278](https://github.com/appium/appium/issues/22278)) ([25d922b](https://github.com/appium/appium/commit/25d922b7d3062c306c1631d6f5c227600ddd226a))
* use exact version for dependencies in monorepo packages instead of ^ ([#22090](https://github.com/appium/appium/issues/22090)) ([86c8f23](https://github.com/appium/appium/commit/86c8f23a670d0bbc2d359a8235828606bd36e6aa))
* Avoid attaching plugins to a non-existing session ([#21964](https://github.com/appium/appium/issues/21964)) ([9f5faf5](https://github.com/appium/appium/commit/9f5faf5bedffe6196742c09c6793a6450af48ac9))
* **logger:** Make sure we always have single logger instance per process ([#21991](https://github.com/appium/appium/issues/21991)) ([4daaa14](https://github.com/appium/appium/commit/4daaa14c29bed129d329d0881a93ecdb9de77676))
* Type imports ([#22025](https://github.com/appium/appium/issues/22025)) ([2f27425](https://github.com/appium/appium/commit/2f27425ea300ca1af1c1da6e4be68d48e7a94346))
<p>Copyright <a href="https://openjsf.org">OpenJS Foundation</a> and Appium contributors. All rights reserved. The <a href="https://openjsf.org">OpenJS Foundation</a> has registered trademarks and uses trademarks. For a list of trademarks of the <a href="https://openjsf.org">OpenJS Foundation</a>, please see our <a href="https://trademark-policy.openjsf.org">Trademark Policy</a> and <a href="https://trademark-list.openjsf.org">Trademark List</a>. Trademarks and logos not indicated on the <a href="https://trademark-list.openjsf.org">list of OpenJS Foundation trademarks</a> are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.</p>
| `platformName` | `string` | yes | The type of platform hosting the app or browser |
| `appium:automationName` | `string` | yes | The name of the Appium driver to use |
| `browserName` | `string` | no | The name of the browser to launch and automate, if the driver supports web browsers as a special case |
| `appium:app` | `string` | no | The path to an installable application |
| `appium:deviceName` | `string` | no | The name of a particular device to automate, e.g., `iPhone 14` (currently only actually useful for specifying iOS simulators, since in other situations it's typically recommended to use a specific device id via the `appium:udid` capability). |
| `appium:platformVersion` | `string` | no | The version of a platform, e.g., for iOS, `16.0` |
| `appium:newCommandTimeout` | `number` | no | The number of seconds the Appium server should wait for clients to send commands before deciding that the client has gone away and the session should shut down. `60` seconds by default. Setting it to zero disables the timer. |
| `appium:noReset` | `boolean` | no | If true, instruct an Appium driver to avoid its usual reset logic during session start and cleanup (default `false`) |
| `appium:fullReset` | `boolean` | no | If true, instruct an Appium driver to augment its usual reset logic with additional steps to ensure maximum environmental reproducibility (default `false`) |
| `appium:eventTimings` | `boolean` | no | If true, instruct an Appium driver to collect [Event Timings](./event-timing.md) (default `false`) |
| `appium:printPageSourceOnFindFailure` | `boolean` | no | If true, collect the page source and print it to the Appium log whenever a request to find an element fails (default `false`) |
Drivers are also able to place more complex constraints on capabilities as a group. For example,
the XCUITest driver recommends that at least one of `browserName`, `appium:app`, or `appium:bundleId`
is included in the capabilities, otherwise it will not be able to auto-install or auto-launch any
application. Each driver will document how it interprets these capabilities and any other
platform-specific requirements.
Some drivers place more complex constraints on capabilities as a group. For example, while the
`appium:app` and `browserName` capabilities are listed above as optional, if you want to launch
a session with a specific app, the XCUITest driver requires that at least one of `appium:app`,
`browserName`, or `appium:bundleId` are included in the capabilities (otherwise it will not know
what app to install and/or launch and will simply open a session on the home screen). Each driver
will document how it interprets these capabilities and any other platform-specific requirements.
The way to construct capabilities and start a session will likely differ depending on your Appium
client. For examples of doing this in each client library, head to the [Ecosystem Clients](../ecosystem/clients.md)
page and click through to the appropriate client documentation.
!!! note
Capabilities are like parameters used when starting a session. After the capabilities are sent
and the session is started, they cannot be changed. If a driver supports updating aspects of
its behaviour in the course of a session, it will provide a [Setting](./settings.md) for this
purpose instead of, or in addition to, a capability.
Each Appium client has its own way of constructing capabilities and starting a session. For
examples of doing this in each client library, head to the [Ecosystem](../ecosystem/index.md) page
and click through to the appropriate client documentation.
Once your capabilities are sent to the server and the session is started, they cannot be
changed. If a driver supports updating its behaviour during a session, it will use the
[Settings API](./settings.md) for this purpose.
## BiDi Protocol Support
Appium supports [WebDriver BiDi](https://w3c.github.io/webdriver-bidi/) protocol since base–driver 9.5.0.
The actual behavior depends on individual drivers while the Appium and the baseーdriver support the protocol.
Please make sure if a driver supports the protocol and what kind of commands/events it supports in the documentation.
In addition to the standard WebDriver protocol (now known as WebDriver Classic), Appium supports the
[WebDriver BiDi](https://w3c.github.io/webdriver-bidi/) protocol. Support for this protocol is
opt-in, and requires the use of the standard `webSocketUrl` capability.
@@ -31,36 +31,28 @@ Appium, when starting it from the command line:
|`--allow-insecure`|Turns on _only_ specified features, except those blocked by `--deny-insecure`. Has no effect when used in combination with `--relaxed-security`|
|`--deny-insecure`|Explicitly turns _off_ specified features, overriding `--relaxed-security` and `--allow-insecure`|
All of the above arguments can also be specified in the [Appium Configuration file](./config.md).
Features passed to `--allow-insecure`/`--deny-insecure` must be specified as a comma-separated list,
and each feature in the list must additionally include a prefix, indicating the driver to which the
feature should apply. The prefix can be either the driver's `automationName`, or the wildcard (`*`)
symbol, if the feature should be applied to all drivers. The prefix and feature name are separated
using the colon character (`:`).
and each feature in the list must additionally include a prefix, indicating the driver to whose
sessions the feature should apply. The prefix can be either the driver's `automationName`, or the
wildcard (`*`) symbol, if the feature should be applied to all drivers. The prefix and feature name
are separated using the colon character (`:`).
For example, `first:foo` refers to the `foo` feature for the `first` driver, whereas `*:bar` refers
to the `bar` feature for all drivers.
## Insecure Features
Each Appium driver is responsible for its own security, and can create its own feature names. Thus,
you should read through the documentation for a particular driver to know which feature names it
might use. Here is an incomplete list of examples from some of Appium's official drivers:
Almost all insecure features are defined on a per-driver or plugin basis, so make sure to read the
documentation for a particular driver/plugin to know which feature names it might use.
Sets the storage access policy of the current browsing context.
#### Parameters
|Name|Description|Type|
|--|--|--|
|`blocked`|Whether storage access should be blocked (`true`) or allowed (`false`)|boolean|
|`origin`|The origin to which the policy should be applied. Must be either a valid URL, or an asterisk (`*`) if the policy should apply to all origins.|string|
#### Response
`null`
## Web Authentication Protocol
The [Web Authentication protocol](https://w3c.github.io/webauthn/) (WebAuthn) is an extension of
|`--address`, `-a`|IPv4/IPv6 address to listen on|string|`0.0.0.0`|
|`--allow-cors`|Allow web browser connections from any host|boolean|`false`|
|`--allow-insecure`|List of [insecure features](../../guides/security.md) that should be allowed in this server's sessions. Individual features can be overridden by `--deny-insecure`. Has no effect in combination with `--relaxed-security`.|array<string>|`[]`|
|`--allow-unknown-args`|Do not exit if unrecognized command-line arguments are passed to the server; ignore them instead. Useful when the Appium CLI is wrapped by external tooling that appends extra flags.|boolean|`false`|
|`--base-path`, `-pa`|Base path to use as the prefix for all webdriver routes running on the server|string|`""`|
|`--callback-address`, `-ca`|Callback IP address|string|`0.0.0.0`|
| `platformName` | Type of platform hosting the app or browser | `string` |
| `appium:automationName` | Name of the Appium driver to use | `string` |
### Optional Capabilities
These capabilities are used in the Appium server/base driver, but are optional, and may have a
default value.
| <div style="width:19em">Capability</div> | Description | Type | Default |
|--|--|--|--|
| `webSocketUrl` | Toggle support of the WebDriver BiDi protocol | `boolean` ||
| `appium:eventTimings` (deprecated) | Toggle collection of [Event Timings](../../guides/event-timing.md). This capability is deprecated - please use the [`getLogEvents`](../api/appium.md#getlogevents) endpoint instead. | `boolean` ||
| `appium:newCommandTimeout` | Number of seconds the Appium server should wait for clients to send commands before stopping the session. A value of `0` disables the timeout. | `number` | `60` |
| `appium:printPageSourceOnFindFailure` | Toggle retrieval of the the page source and its printing to the Appium log, whenever a request to find an element fails | `boolean` ||
### Validated Capabilities
These capabilities are not directly used in the Appium server/base driver, but are still subject to
validation checks due to their relevance in other drivers. The actual handling of these
capabilities is optional and entirely driver-dependent.
Here you can find links to additional Appium resources around the web:
## Websites
- [Appium Pro](https://appiumpro.com) - a blog and newsletter written by one of Appium's
maintainers, Jonathan Lipps, with lots of useful guides
## Online Courses
- [Appium and Selenium Fundamentals](https://ui.headspin.io/university/learn/appium-selenium-fundamentals-2020) - a comprehensive video course on learning Python, Selenium, and Appium by Jonathan Lipps
@@ -26,3 +21,4 @@ maintainers, Jonathan Lipps, with lots of useful guides
@@ -31,36 +31,30 @@ Appium, when starting it from the command line:
| `--allow-insecure` | Turns on _only_ specified features, except those blocked by `--deny-insecure`. Has no effect when used in combination with `--relaxed-security` |
| `blocked` | Whether storage access should be blocked (`true`) or allowed (`false`) | boolean |
| `origin` | The origin to which the policy should be applied. Must be either a valid URL, or an asterisk (`*`) if the policy should apply to all origins. | string |
#### Response
`null`
## Web Authentication Protocol
The [Web Authentication protocol](https://w3c.github.io/webauthn/) (WebAuthn) is an extension of
| `--address`, `-a` | IPv4/IPv6 address to listen on | string | `0.0.0.0` |
| `--allow-cors` | Allow web browser connections from any host | boolean | `false` |
| `--allow-insecure` | List of [insecure features](../../guides/security.md) that should be allowed in this server's sessions. Individual features can be overridden by `--deny-insecure`. Has no effect in combination with `--relaxed-security`. | array<string> | `[]` |
| `--allow-unknown-args` | Do not exit if unrecognized command-line arguments are passed to the server; ignore them instead. Useful when the Appium CLI is wrapped by external tooling that appends extra flags. | boolean | `false` |
| `--base-path`, `-pa` | Base path to use as the prefix for all webdriver routes running on the server | string | `""` |
| `webSocketUrl` | Toggle support of the WebDriver BiDi protocol | `boolean` | |
| `appium:eventTimings` (deprecated) | Toggle collection of [Event Timings](../../guides/event-timing.md). This capability is deprecated - please use the [`getLogEvents`](../api/appium.md#getlogevents) endpoint instead. | `boolean` | |
| `appium:newCommandTimeout` | Number of seconds the Appium server should wait for clients to send commands before stopping the session. A value of `0` disables the timeout. | `number` | `60` |
| `appium:printPageSourceOnFindFailure` | Toggle retrieval of the the page source and its printing to the Appium log, whenever a request to find an element fails | `boolean` | |
### Validated Capabilities
These capabilities are not directly used in the Appium server/base driver, but are still subject to
validation checks due to their relevance in other drivers. The actual handling of these
capabilities is optional and entirely driver-dependent.
Here you can find links to additional Appium resources around the web:
## Websites
- [Appium Pro](https://appiumpro.com) - a blog and newsletter written by one of Appium's
maintainers, Jonathan Lipps, with lots of useful guides
## Online Courses
- [Appium and Selenium Fundamentals](https://ui.headspin.io/university/learn/appium-selenium-fundamentals-2020) - a comprehensive video course on learning Python, Selenium, and Appium by Jonathan Lipps
@@ -26,3 +21,4 @@ Here you can find links to additional Appium resources around the web:
We're thrilled to announce that Appium Conf is back and going online for 2024! This is the official Appium conference where you can learn all about what's new in Appium 2.0 and explore the latest in automating tests for devices, mobile apps, and desktop applications.
@@ -17,29 +17,29 @@ We're thrilled to announce that Appium Conf is back and going online for 2024! T
</a>
</div>
## Mark Your Calendars: September 13, 2024
## 标记您的日历:2024年9月13日
Join us on September 13, 2024, for a full day of inspiring and practical talks from the Appium team and the world's top mobile testing and automation experts. With Appium 2.0 now well-established, this is your opportunity to dive deep and learn how to maximize its potential.
1. **Gain Insights**: Hear interesting insights and inspiring case studies from global experts and the core Appium team.
2. **Improve Your Strategy**: Gain valuable knowledge to enhance your own automation strategy.
3. **Network**: Make connections with Appium users from around the globe.
4. **Learn from Specialists**: Benefit from Appium specialists' expertise on a variety of topics.
1. **获得见解**:听取全球专家和核心Appium团队的有趣见解和鼓舞人心的案例研究。
2. **改进您的战略**:获得有价值的知识,以增强您自己的自动化战略。
3. **网络**:与来自全球的Appium用户建立联系。
4. **向专家学习**:从Appium专家在各种主题上的专业知识中受益。
## Call for Proposals: Share Your Knowledge!
## 征集提案:分享您的知识!
We're looking for a diverse range of speakers from around the globe who are eager to share innovative ideas and use-cases of mobile test automation. If you have experience with Appium and insights that could benefit the community of test practitioners, we want to hear from you!
Don't miss this chance to contribute to the Appium community and showcase your expertise on a global stage.
不要错过这个机会,为Appium社区做出贡献,并在全球舞台上展示你的专业知识。
## How to Submit Your Proposal
## 如何提交您的提案
Visit our website at [https://appiumconf.com/](https://appiumconf.com/) and [Submit a Proposal](https://confengine.com/conferences/appium-conf-2024/proposals?utm_medium=referal&utm_source=appium.io&utm_campaign=launch). We're excited to see your innovative ideas and experiences with Appium!
Keep an eye on our website and social media channels for updates on the conference schedule, keynote speakers, and more exciting details about Appium Conf 2024.
@@ -29,7 +29,7 @@ In lieu of a separate file, configuration can be embedded in a project's `packag
```
When an Appium server is started via the `appium` executable, the `init` function in `lib/main.js`
will call into `lib/config-file.js` to load and/or search for a configuration file and in
will call into `lib/bootstrap/config-file.js` to load and/or search for a configuration file and in
`package.json`.
!!! note
@@ -72,7 +72,7 @@ It is more straightforward to explain how config files are validated, so we'll s
### Validating Config Files
When a config file is found (`lib/config-file.js`), it will call the `validate` function exported
When a config file is found (`lib/bootstrap/config-file.js`), it will call the `validate` function exported
from `lib/schema/schema.js` with the contents of the config file. In turn, this asks `ajv` to
validate the data against the schema that Appium has provided it.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.