Migration depuis CircleCI avec GitHub Actions Importer

Découvrez comment utiliser GitHub Actions Importer pour automatiser la migration de vos pipelines CircleCI vers GitHub Actions.

Dans cet article

Mentions légales

À propos de la migration depuis CircleCI avec GitHub Actions Importer

Les instructions ci-dessous vous guident tout au long de la configuration de votre environnement pour utiliser GitHub Actions Importer afin de migrer des pipelines CircleCI vers GitHub Actions.

Prérequis

  • Un compte ou une organisation CircleCI avec des projets et des pipelines que vous souhaitez convertir en workflows GitHub Actions.

  • Un accès pour créer un jeton d’API personnel CircleCI pour votre compte ou organisation.

  • Un environnement dans lequel vous pouvez exécuter des conteneurs basés sur Linux et installer les outils nécessaires.

    Remarque : Le conteneur GitHub Actions Importer et l’interface CLI n’ont pas besoin d’être installés sur le même serveur que votre plateforme CI.

Limites

Il existe certaines limitations lors de la migration de CircleCI vers GitHub Actions avec GitHub Actions Importer :

  • La mise en cache automatique entre les travaux de différents workflows n’est pas prise en charge.
  • La commande audit est uniquement prise en charge lorsque vous utilisez un compte d’organisation CircleCI. Les commandes dry-run et migrate peuvent être utilisées avec un compte d’organisation ou d’utilisateur CircleCI.

Tâches manuelles

Certaines constructions CircleCI doivent être migrées manuellement. Il s’agit notamment des paramètres suivants :

  • Contextes
  • Variables d’environnement au niveau du projet
  • Propriétés de travail inconnues
  • Orbes inconnus

Installation de l’extension CLI GitHub Actions Importer

  1. Installez l’extension CLI GitHub Actions Importer :

    Bash
    gh extension install github/gh-actions-importer

  2. Vérifiez que l’extension est installée :

    $ gh actions-importer -h
Options:
  -?, -h, --help  Show help and usage information

Commands:
  update     Update to the latest version of GitHub Actions Importer.
  version    Display the version of GitHub Actions Importer.
  configure  Start an interactive prompt to configure credentials used to authenticate with your CI server(s).
  audit      Plan your CI/CD migration by analyzing your current CI/CD footprint.
  forecast   Forecast GitHub Actions usage from historical pipeline utilization.
  dry-run    Convert a pipeline to a GitHub Actions workflow and output its yaml file.
  migrate    Convert a pipeline to a GitHub Actions workflow and open a pull request with the changes.

Configuration des informations d’identification

La commande CLI configure est utilisée pour définir les informations d’identification et les options requises pour GitHub Actions Importer lors de l’utilisation de CircleCI et de GitHub.

  1. Créez un personal access token (classic) GitHub. Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».

    Votre jeton doit avoir l’étendue workflow.

    Après avoir créé le jeton, copiez-le et enregistrez-le en lieu sûr en vue de l’utiliser ultérieurement.

  2. Créez un jeton d’API personnel CircleCI. Pour plus d’informations, consultez Gestion des jetons d’API dans la documentation de CircleCI.

    Après avoir créé le jeton, copiez-le et enregistrez-le en lieu sûr en vue de l’utiliser ultérieurement.

  3. Dans votre terminal, exécutez la commande CLI GitHub Actions Importer configure :

    gh actions-importer configure

    La commande configure vous invite à entrer les informations suivantes :

    • Pour « Quels fournisseurs CI configurez-vous ? », utilisez les touches de direction pour sélectionner CircleCI, appuyez sur Espace pour le sélectionner, puis appuyez sur Entrée.
    • Pour « Personal access token pour GitHub », entrez la valeur du personal access token (classic) que vous avez créé, puis appuyez sur Entrée.
    • Pour « URL de base de l’instance GitHub », appuyez sur Entrée pour accepter la valeur par défaut (https://github.com).
    • Pour « Personal access token pour CircleCI », entrez la valeur du jeton d’API personnel CircleCI que vous avez créé, puis appuyez sur Entrée.
    • Pour « URL de base de l’instance CircleCI », appuyez sur Entrée pour accepter la valeur par défaut (https://circleci.com).
    • Pour « Nom de l’organisation CircleCI », entrez le nom de votre organisation CircleCI et appuyez sur Entrée.

    Voici un exemple de la commande configure :

    $ gh actions-importer configure
✔ Which CI providers are you configuring?: CircleCI
Enter the following values (leave empty to omit):
✔ Personal access token for GitHub: ***************
✔ Base url of the GitHub instance: https://github.com
✔ Personal access token for CircleCI: ********************
✔ Base url of the CircleCI instance: https://circleci.com
✔ CircleCI organization name: mycircleciorganization
Environment variables successfully updated.

  4. Dans votre terminal, exécutez la commande CLI GitHub Actions Importer update pour vous connecter au Container registry GitHub Packages et vérifier que l’image conteneur est mise à jour vers la dernière version :

    gh actions-importer update

    La sortie de la commande devrait ressembler à la sortie ci-dessous :

    Updating ghcr.io/actions-importer/cli:latest...
ghcr.io/actions-importer/cli:latest up-to-date

Effectuer un audit de CircleCI

Vous pouvez utiliser la commande audit pour obtenir une vue d’ensemble de tous les projets d’une organisation CircleCI.

La commande audit effectue les étapes suivantes :

  1. Extrait tous les projets définis dans une organisation CircleCI.
  2. Convertit chaque pipeline en workflow GitHub Actions équivalent.
  3. Génère un rapport qui résume la complexité et l’exhaustivité d’une migration avec GitHub Actions Importer.

Exécution de la commande audit

Pour effectuer un audit d’une organisation CircleCI, exécutez la commande suivante dans votre terminal :

gh actions-importer audit circle-ci --output-dir tmp/audit

Inspection des résultats de l’audit

Les fichiers dans le répertoire de sortie spécifié contiennent les résultats de l’audit. Consultez le fichier audit_summary.md pour obtenir un résumé des résultats de l’audit.

Le résumé de l’audit comporte les sections suivantes.

Pipelines

La section « Pipelines » contient des statistiques générales concernant le taux de conversion effectué par GitHub Actions Importer.

Vous trouverez ci-dessous quelques termes clés qui peuvent apparaître dans la section « Pipelines » :

  • Les pipelines réussis sont ceux dont 100 % des constructions de pipeline et des éléments individuels ont été convertis automatiquement en leur équivalent GitHub Actions.
  • Les pipelines partiellement réussis sont ceux dont la totalité des constructions de pipeline ont été converties ; toutefois, certains éléments individuels n’ont pas été convertis automatiquement en leur équivalent GitHub Actions.
  • Les pipelines non pris en charge sont des types de définition qui ne sont pas pris en charge par GitHub Actions Importer.
  • Les pipelines ayant échoué sont ceux qui ont rencontré une erreur irrécupérable lors de la conversion. Cela peut se produire pour l’une des trois raisons suivantes :
    • Le pipeline a été mal configuré à l’origine et n’était pas valide.
    • GitHub Actions Importer a rencontré une erreur interne lors de sa conversion.
    • Une réponse réseau infructueuse a rendu le pipeline inaccessible, ce qui est souvent dû à des informations d’identification non valides.

Étapes de génération

La section « Étapes de génération » contient une vue d’ensemble des étapes de génération individuelles utilisées dans tous les pipelines ainsi que le nombre d’étapes converties automatiquement par GitHub Actions Importer.

Vous trouverez ci-dessous quelques termes clés qui peuvent apparaître dans la section « Étapes de génération » :

  • Une étape de génération connue est une étape qui a été automatiquement convertie en action équivalente.
  • Une étape de génération inconnue est une étape qui n’a pas été automatiquement convertie en action équivalente.
  • Une étape de génération non prise en charge est une étape qui est :
    • Fondamentalement non prise en charge par GitHub Actions.
    • Configuré d’une manière incompatible avec GitHub Actions.
  • Une action est une liste des actions qui ont été utilisées dans les workflows convertis. Cela peut être important pour :
    • Rassembler la liste des actions à synchroniser avec votre instance, si vous utilisez GitHub Enterprise Server.
    • Définir une liste d’autorisation au niveau de l’organisation des actions utilisées. Cette liste d’actions est une liste complète d’actions que vos équipes de sécurité ou de conformité peuvent avoir besoin d’examiner.

Tâches manuelles

La section « Tâches manuelles » contient une vue d’ensemble des tâches que GitHub Actions Importer ne peut pas accomplir automatiquement et que vous devez effectuer manuellement.

Vous trouverez ci-dessous quelques termes clés qui peuvent apparaître dans la section « Tâches manuelles » :

  • Un secret est un secret au niveau de l’organisation ou du dépôt qui est utilisé dans les pipelines convertis. Ces secrets doivent être créés manuellement dans GitHub Actions pour que ces pipelines fonctionnent correctement. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».
  • Un exécuteur auto-hébergé fait référence à une étiquette d’un exécuteur référencé dans un pipeline converti qui n’est pas un exécuteur hébergé par GitHub. Vous devez définir manuellement ces exécuteurs pour que ces pipelines fonctionnent correctement.

Fichiers

La dernière section du rapport d’audit fournit un manifeste de tous les fichiers qui ont été écrits sur le disque pendant l’audit.

À chaque fichier de pipeline correspond une série de fichiers inclus dans l’audit, notamment :

  • Le pipeline d’origine tel qu’il a été défini dans GitHub.
  • Toutes les réponses réseau utilisées pour convertir le pipeline.
  • Le fichier de workflow converti.
  • Les traces de pile qui peuvent être utilisées pour résoudre les problèmes liés à une conversion de pipeline ayant échoué.

De plus, le fichier workflow_usage.csv contient une liste séparée par des virgules de l’ensemble des actions, secrets et exécuteurs qui sont utilisés par chaque pipeline converti avec succès. Cela peut être utile pour déterminer quels workflows utilisent quelles actions, quels secrets ou quels exécuteurs, et pour effectuer des révisions de sécurité.

Prévision de l’utilisation potentielle de GitHub Actions

Vous pouvez utiliser la commande forecast pour prévoir l’utilisation potentielle de GitHub Actions en calculant des métriques à partir des exécutions de pipeline terminées dans CircleCI.

Exécution de la commande forecast

Pour faire une prévision de l’utilisation potentielle de GitHub Actions, exécutez la commande suivante dans votre terminal. Par défaut, GitHub Actions Importer inclut les sept jours précédents dans le rapport de prévision.

gh actions-importer forecast circle-ci --output-dir tmp/forecast_reports

Inspection du rapport de prévision

Le fichier forecast_report.md dans le répertoire de sortie spécifié contient les résultats de la prévision.

Voici quelques termes clés qui peuvent apparaître dans le rapport de prévision :

  • Le nombre de travaux correspond au nombre total de travaux terminés.

  • Le nombre de pipelines correspond au nombre de pipelines uniques utilisés.

  • Le temps d’exécution décrit le temps passé par un exécuteur sur un travail. Cette métrique peut être utilisée pour planifier le coût des exécuteurs hébergés par GitHub.

    Cette métrique est corrélée au montant que vous devez vous attendre à dépenser dans GitHub Actions. Cela varie en fonction du matériel utilisé pendant ces minutes. Vous pouvez utiliser la calculatrice de prix GitHub Actions pour estimer les coûts.

  • Les métriques de temps de file d’attente décrivent le temps passé par un travail à attendre qu’un exécuteur soit disponible pour l’exécuter.

  • Les métriques de travaux simultanés décrivent le nombre de travaux en cours d’exécution à un moment donné. Cette métrique peut être utilisée pour définir le nombre d’exécuteurs que vous devez configurer.

De plus, ces métriques sont définies pour chaque file d’attente d’exécuteurs dans CircleCI. C’est particulièrement utile s’il existe une combinaison d’exécuteurs hébergés ou auto-hébergés ou de machines à spécifications élevées ou faibles, afin que vous puissiez voir des métriques spécifiques à différents types d’exécuteurs.

Effectuer une migration test d’un pipeline CircleCI

Vous pouvez utiliser la commande dry-run pour convertir un pipeline CircleCI en workflow GitHub Actions équivalent. Une exécution test crée les fichiers de sortie dans un répertoire spécifié, mais n’ouvre pas de demande de tirage pour migrer le pipeline.

Pour effectuer une exécution test de migration de votre projet CircleCI vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant my-circle-ci-project par le nom de votre projet CircleCI.

gh actions-importer dry-run circle-ci --output-dir tmp/dry-run --circle-ci-project my-circle-ci-project

Vous pouvez afficher les journaux de l’exécution test et les fichiers de workflow convertis dans le répertoire de sortie spécifié.

Pour tout ce que GitHub Actions Importer n’a pas pu convertir automatiquement, comme des étapes de génération inconnues ou un pipeline partiellement réussi, vous pouvez créer des transformateurs personnalisés pour personnaliser davantage le processus de conversion. Pour plus d’informations, consultez « Extension GitHub Actions Importer avec des transformateurs personnalisés ».

Effectuer une migration de production d’un pipeline CircleCI

Vous pouvez utiliser la commande migrate pour convertir un pipeline CircleCI et ouvrir une demande de tirage avec le workflow GitHub Actions équivalent.

Exécution de la commande migrate

Pour migrer un pipeline CircleCI vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant la valeur target-url par l’URL de votre dépôt GitHub et my-circle-ci-project par le nom de votre projet CircleCI.

gh actions-importer migrate circle-ci --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --circle-ci-project my-circle-ci-project

La sortie de la commande inclut l’URL de la demande de tirage qui ajoute le workflow converti à votre dépôt. Voici un exemple de sortie réussie :

$ gh actions-importer migrate circle-ci --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --circle-ci-project my-circle-ci-project
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'
[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'

Inspection de la demande de tirage

La sortie d’une exécution réussie de la commande migrate contient un lien vers la nouvelle demande de tirage qui ajoute le workflow converti à votre dépôt.

Voici quelques éléments importants de la demande de tirage :

  • Dans la description de la demande de tirage, une section appelée Étapes manuelles, qui liste les étapes que vous devez effectuer manuellement avant de pouvoir terminer la migration de vos pipelines vers GitHub Actions. Par exemple, cette section peut vous indiquer de créer des secrets utilisés dans vos workflows.
  • Fichier de workflows converti. Sélectionnez l’onglet Fichiers changés dans la demande de tirage pour afficher le fichier de workflow à ajouter à votre dépôt GitHub.

Une fois que vous avez terminé d’inspecter la demande de tirage, vous pouvez la fusionner pour ajouter le workflow à votre dépôt GitHub.

Informations de référence

Cette section contient des informations de référence sur les variables d’environnement, les arguments facultatifs et la syntaxe prise en charge lors de l’utilisation de GitHub Actions Importer pour effectuer une migration à partir de CircleCI.

Utilisation de variables d’environnement

GitHub Actions Importer utilise des variables d’environnement pour sa configuration d’authentification. Ces variables sont définies lors du processus de configuration au moyen de la commande configure. Pour plus d’informations, consultez la section « Configuration des informations d’identification ».

GitHub Actions Importer utilise les variables d’environnement suivantes pour se connecter à votre instance CircleCI :

  • GITHUB_ACCESS_TOKEN : personal access token (classic) utilisé pour créer des demandes de tirage avec un workflow converti (nécessite les étendues repo et workflow).
  • GITHUB_INSTANCE_URL : URL de l’instance GitHub cible (par exemple, https://github.com).
  • CIRCLE_CI_ACCESS_TOKEN : Jeton d’API personnel CircleCI utilisé pour l’authentification auprès de votre instance CircleCI.
  • CIRCLE_CI_INSTANCE_URL : URL de l’instance CircleCI (par exemple, https://circleci.com). Si la variable n’est pas définie, https://circleci.com est utilisé comme valeur par défaut.
  • CIRCLE_CI_ORGANIZATION : Nom d’organisation de votre instance CircleCI.
  • CIRCLE_CI_PROVIDER : Emplacement où le fichier source de votre pipeline est stocké (par exemple github). Actuellement, seul GitHub est pris en charge.
  • CIRCLE_CI_SOURCE_GITHUB_ACCESS_TOKEN (Facultatif) : personal access token (classic) utilisé pour l’authentification auprès de votre instance GitHub source (nécessite l’étendue repo). S’il n’est pas fourni, la valeur de GITHUB_ACCESS_TOKEN est utilisée à la place.
  • CIRCLE_CI_SOURCE_GITHUB_INSTANCE_URL (Facultatif) : URL de l’instance GitHub source. Si elle n’est pas fournie, la valeur de GITHUB_INSTANCE_URL est utilisée à la place.

Ces variables d’environnement peuvent être spécifiées dans un fichier .env.local chargé par GitHub Actions Importer lors de son exécution.

Arguments facultatifs

Vous pouvez utiliser des arguments facultatifs avec les sous-commandes GitHub Actions Importer pour personnaliser votre migration.

--source-file-path

Vous pouvez utiliser l’argument --source-file-path avec les sous-commandes forecast, dry-run ou migrate.

Par défaut, GitHub Actions Importer récupère le contenu du pipeline à partir du contrôle de code source. L’argument --source-file-path indique à GitHub Actions Importer d’utiliser le chemin du fichier source spécifié à la place.

Par exemple :

gh actions-importer dry-run circle-ci --output-dir ./output/ --source-file-path ./path/to/.circleci/config.yml

Si vous souhaitez fournir plusieurs fichiers sources lors de l’exécution de la sous-commande forecast, vous pouvez utiliser la correspondance de modèle dans la valeur du chemin de fichier. Par exemple, gh forecast --source-file-path ./tmp/previous_forecast/jobs/*.json fournit à GitHub Actions Importer tous les fichiers sources qui correspondent au chemin de fichier ./tmp/previous_forecast/jobs/*.json.

--config-file-path

Vous pouvez utiliser l’argument --config-file-path avec les sous-commandes audit, dry-run et migrate.

Par défaut, GitHub Actions Importer récupère le contenu du pipeline à partir du contrôle de code source. L’argument --config-file-path indique à GitHub Actions Importer d’utiliser les fichiers sources spécifiés à la place.

L’argument --config-file-path peut également être utilisé pour spécifier le référentiel vers lequel une action composite convertie doit être migrée.

Exemple Audit

Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié pour effectuer un audit.

gh actions-importer audit circle-ci --output-dir ./output/ --config-file-path ./path/to/circle-ci/config.yml

Pour auditer une instance CircleCI avec un fichier config, celui-ci doit être au format suivant et chaque repository_slug doit être unique :

source_files:
  - repository_slug: circle-org-name/circle-project-name
    path: path/to/.circleci/config.yml
  - repository_slug: circle-org-name/some-other-circle-project-name
    path: path/to/.circleci/config.yml
Exemple d’exécution test

Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié comme fichier source pour effectuer une exécution test.

Le pipeline est sélectionné en faisant correspondre la valeur repository_slug du fichier de configuration à celle des options --circle-ci-organization et --circle-ci-project. path est ensuite utilisé pour tirer (pull) le fichier source spécifié.

gh actions-importer dry-run circle-ci --circle-ci-project circle-org-name/circle-project-name --output-dir ./output/ --config-file-path ./path/to/circle-ci/config.yml
Spécifier le référentiel d’actions composites converties

GitHub Actions Importer utilise le fichier YAML fourni à l’argument --config-file-path pour déterminer le référentiel vers lequel les actions composites converties sont migrées.

Pour commencer, vous devez exécuter un audit sans l’argument --config-file-path :

gh actions-importer audit circle-ci --output-dir ./output/

La sortie de cette commande contient un fichier nommé config.yml qui contient lui-même une liste de toutes les actions composites qui ont été converties par GitHub Actions Importer. Par exemple, le fichier config.yml peut avoir le contenu suivant :

composite_actions:
  - name: my-composite-action.yml
    target_url: https://github.com/octo-org/octo-repo
    ref: main

Vous pouvez utiliser ce fichier pour spécifier le référentiel et la référence auxquels un workflow réutilisable ou une action composite doit être ajouté. Vous pouvez ensuite utiliser l’argument --config-file-path pour fournir le fichier config.yml à GitHub Actions Importer. Par exemple, vous pouvez utiliser ce fichier lors de l’exécution d’une commande migrate pour ouvrir une demande de tirage pour chaque référentiel unique défini dans le fichier config :

gh actions-importer migrate circle-ci --circle-ci-project my-project-name --output-dir output/ --config-file-path config.yml --target-url https://github.com/my-org/my-repo

--include-from

Vous pouvez utiliser l’argument --include-from avec la sous-commande audit.

L’argument --include-from spécifie un fichier qui contient une liste de dépôts délimitée par des lignes à inclure dans l’audit d’une organisation CircleCI. Tous les dépôts qui ne sont pas inclus dans le fichier sont exclus de l’audit.

Par exemple :

gh actions-importer audit circle-ci --output-dir ./output/ --include-from repositories.txt

Le fichier fourni pour ce paramètre doit être une liste de référentiels délimitée par des lignes, par exemple :

repository_one
repository_two
repository_three

Syntaxe prise en charge pour les pipelines CircleCI

Le tableau suivant montre le type de propriétés que GitHub Actions Importer peut actuellement convertir.

Pipelines CircleCIGitHub ActionsStatut
cron triggers
  • on.schedule
Prise en charge
Environnement
  • env
  • jobs.<job_id>.env
  • jobs.<job_id>.steps.env
Prise en charge
executors
  • runs-on
Pris en charge
jobs
  • jobs
Prise en charge
travail
  • jobs.<job_id>
  • jobs.<job_id>.name
Prise en charge
matrice
  • jobs.<job_id>.strategy
  • jobs.<job_id>.strategy.matrix
Prise en charge
parameters
  • env
  • workflow-dispatch.inputs
Prise en charge
steps
  • jobs.<job_id>.steps
Prise en charge
when, unless
  • jobs.<job_id>.if
Prise en charge
Déclencheurs
  • on
Prise en charge
executors
  • container
  • services
Prise en charge partielle
orbs
  • actions
Prise en charge partielle
executors
  • self hosted runners
Non pris en charge
configurerNon applicableNon pris en charge
versionNon applicableNon pris en charge

Pour plus d’informations sur les correspondances de concepts et d’orbes CircleCI, consultez le dépôt github/gh-actions-importer.

Correspondances des variables d’environnement

GitHub Actions Importer utilise les correspondances dans le tableau ci-dessous pour convertir les variables d’environnement CircleCI par défaut en l’équivalent le plus proche dans GitHub Actions.

CircleCIGitHub Actions
CI$CI
CIRCLE_BRANCH${{ github.ref }}
CIRCLE_JOB${{ github.job }}
CIRCLE_PR_NUMBER${{ github.event.number }}
CIRCLE_PR_REPONAME${{ github.repository }}
CIRCLE_PROJECT_REPONAME${{ github.repository }}
CIRCLE_SHA1${{ github.sha }}
CIRCLE_TAG${{ github.ref }}
CIRCLE_USERNAME${{ github.actor }}
CIRCLE_WORKFLOW_ID${{ github.run_number }}
CIRCLE_WORKING_DIRECTORY${{ github.workspace }}
<< pipeline.id >>${{ github.workflow }}
<< pipeline.number >>${{ github.run_number }}
<< pipeline.project.git_url >>$GITHUB_SERVER_URL/$GITHUB_REPOSITORY
<< pipeline.project.type >>github
<< pipeline.git.tag >>${{ github.ref }}
<< pipeline.git.branch >>${{ github.ref }}
<< pipeline.git.revision >>${{ github.event.pull_request.head.sha }}
<< pipeline.git.base_revision >>${{ github.event.pull_request.base.sha }}

Certaines parties ont été adaptées à partir de https://github.com/github/gh-actions-importer/ sous la licence MIT :

MIT License

Copyright (c) 2022 GitHub

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.