Skip to main content

Esta versión de GitHub Enterprise Server se discontinuó el 2024-03-26. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

database upgrade

Actualiza una base de datos para que las herramientas actuales puedan usarla.

¿Quién puede utilizar esta característica?

Las licencias de GitHub CodeQL se otorgan por usuario tras la instalación. Puedes usar CodeQL solo para determinadas tareas según las restricciones de las licencias. Para obtener más información, vea «Acerca de la CLI de CodeQL».

Si tienes una licencia de GitHub Advanced Security, puedes usar CodeQL para el análisis automatizado, la integración continua y la entrega continua. Para obtener más información, vea «Acerca de GitHub Advanced Security».

En este contenido se describe la versión más reciente de CodeQL CLI. Para obtener más información sobre esta versión, consulta https://github.com/github/codeql-cli-binaries/releases.

Para ver detalles de las opciones disponibles para este comando en una versión anterior, ejecuta el comando con la opción --help en el terminal.

Sinopsis

Shell
codeql database upgrade [--threads=<num>] [--ram=<MB>] <options>... -- <database>

Descripción

Actualiza una base de datos para que las herramientas actuales puedan usarla.

Esta operación reescribe una base de datos de CodeQL para que sea compatible con las bibliotecas de QL que se encuentran en la ruta de búsqueda del paquete de QL, si es necesario.

Si es necesario actualizar, la operación es irreversible. Después, la base de datos no se podrá usar con las bibliotecas que eran actuales en el momento de la creación.

Opciones

Opciones principales

<database>

[Obligatorio] Ruta de acceso a la base de datos CodeQL que se va a actualizar.

--search-path=<dir>[:<dir>...]

Lista de directorios en la que se pueden encontrar paquetes de QL que contienen recetas de actualización. Cada directorio puede ser un paquete de QL (o una agrupación de paquetes que contenga un archivo .codeqlmanifest.json en la raíz) o el elemento primario inmediato de uno o varios directorios de este tipo.

Si la ruta de acceso contiene árboles de directorios, su orden define la prioridad entre ellos: si un nombre de paquete que se debe resolver tiene coincidencias en más de uno de los árboles de directorio, tiene prioridad el que se indica primero.

Apuntar a una extracción del repositorio CodeQL de código abierto debería funcionar al consultar uno de los lenguajes que residen allí.

(Nota: En Windows, el separador de ruta de acceso es ;).

--additional-packs=<dir>[:<dir>...]

[Avanzado] Si se da esta lista de directorios, se buscarán actualizaciones en ellos antes que en los incluidos en --search-path. El orden entre ellos no importa; si se encuentra un nombre de paquete en dos lugares diferentes de esta lista es un error.

Esto resulta útil si estás desarrollando provisionalmente una nueva versión de un paquete que también aparece en la ruta de acceso predeterminada. Por otro lado, no se recomienda reemplazar esta opción en un archivo de configuración; algunas acciones internas agregarán esta opción sobre la marcha y reemplazarán cualquier valor configurado.

(Nota: En Windows, el separador de ruta de acceso es ;).

--target-dbscheme=<file>

El elemento dbscheme de destino al que queremos actualizar. Si no se proporciona, se construirá una ruta de actualización máxima.

--target-sha=<sha>

[Avanzado] Alternativa a --target-dbscheme que proporciona el hash interno del elemento dbscheme de destino, en lugar del archivo dbscheme.

--[no-]allow-downgrades

Incluye los cambios pertinentes a una versión anterior si no hay ninguna actualización.

Opciones para controlar la evaluación de las consultas de actualización.

--[no-]tuple-counting

[Avanzado] Muestra recuentos de tuplas para cada uno de los pasos de evaluación en los registros del evaluador de consultas. Si se proporciona la opción --evaluator-log, los recuentos de tuplas se incluirán en los registros JSON estructurados y basados en texto generados por el comando. (Esto puede ser útil para la optimización del rendimiento del código QL complejo).

--timeout=<seconds>

[Avanzado] Establece la duración del tiempo de espera para la evaluación de consultas, en segundos.

La característica de tiempo de espera está pensada para detectar los casos en los que una consulta compleja tardaría "una eternidad" en evaluarse. No es una forma eficaz de limitar la cantidad total de tiempo que puede tardar la evaluación de la consulta. La evaluación podrá continuar siempre y cuando cada parte cronometrada por separado del cálculo se complete dentro del plazo de tiempo de espera. Actualmente, estas partes cronometradas por separado son "capas de RA" de la consulta optimizada, lo cual puede cambiar en el futuro.

Si no se especifica el tiempo de espera o se define como 0, no se establecerá tiempo de espera (excepto para codeql test run, donde el tiempo de espera predeterminado es de 5 minutos).

-j, --threads=<num>

Usa todos estos subprocesos para evaluar las consultas.

De manera predeterminada, su valor es 1. Puedes pasar 0 para usar un subproceso por núcleo en la máquina o -N para dejar N núcleos sin usar (excepto que aún se usa al menos un subproceso).

--[no-]save-cache

[Avanzado] Escribe los resultados intermedios de forma activa en la caché del disco. Esto tarda más y usa (mucho) más espacio en disco, pero puede acelerar la ejecución posterior de consultas similares.

--[no-]expect-discarded-cache

[Avanzado] Toma decisiones sobre qué predicados se van a evaluar y qué se va a escribir en la memoria caché del disco, si se asume que la caché se descartará después de ejecutar las consultas.

--[no-]keep-full-cache

[Avanzado] No limpies la caché del disco una vez finalizada la evaluación. Esto puede ahorrar tiempo si después vas a ejecutar codeql dataset cleanup o codeql database cleanup de todos modos.

--max-disk-cache=<MB>

Establece la cantidad máxima de espacio que puede usar la caché del disco para los resultados intermedios de la consulta.

Si este tamaño no está configurado explícitamente, el evaluador intentará usar una cantidad "razonable" de espacio de caché, en función del tamaño del conjunto de datos y de la complejidad de las consultas. Establecer explícitamente un límite mayor que este uso predeterminado permitirá el almacenamiento en caché adicional que puede acelerar las consultas posteriores.

--min-disk-free=<MB>

[Avanzado] Establece la cantidad de espacio libre de destino en el sistema de archivos.

Si no se proporciona --max-disk-cache, el evaluador intentará reducir el uso de la caché del disco si el espacio libre en el sistema de archivos cae por debajo de este valor.

--min-disk-free-pct=<pct>

[Avanzado] Establece la fracción de destino del espacio libre en el sistema de archivos.

Si no se proporciona --max-disk-cache, el evaluador intentará reducir el uso de la caché del disco si el espacio libre en el sistema de archivos cae por debajo de este porcentaje.

--external=<pred>=<file.csv>

Un archivo CSV que contiene filas para el predicado <pred> externo. Se pueden especificar varias opciones --external.

--xterm-progress=<mode>

[Avanzado] Controla si se va a mostrar el seguimiento del progreso durante la evaluación de QL mediante las secuencias de control xterm. Los valores posibles son:

no: nunca se produce un progreso destacado; se asume que el terminal es lento.

auto (predeterminado) : detecta automáticamente si el comando se ejecuta en un terminal adecuado.

yes: se asume que el terminal comprende las secuencias de control xterm. La característica sigue dependiendo de poder detectar automáticamente el tamaño del terminal y también se deshabilitará si se proporciona -q.

25x80 (o similar): como yes, además de proporcionar también explícitamente el tamaño del terminal.

25x80:/dev/pts/17 (o similar): muestra un progreso destacado en un terminal distinto de stderr. Resulta útil sobre todo para las pruebas internas.

Opciones para controlar la salida de registros de evaluador estructurados

--evaluator-log=<file>

[Avanzado] Genera registros estructurados sobre el rendimiento del evaluador en el archivo especificado. El formato de este archivo de registro está sujeto a cambios sin previo aviso, pero será una secuencia de objetos JSON separados por dos caracteres de nueva línea (opción predeterminada) o por uno si se pasa la opción --evaluator-log-minify. Usa codeql generate log-summary <file> para generar un resumen más estable de este archivo y evita analizar el archivo directamente. Si el archivo ya existe, se sobrescribirá.

--evaluator-log-minify

[Avanzado] Si se pasa la opción --evaluator-log, al pasar también esta opción se minimizará el tamaño del registro JSON generado, a costa de un resultado mucho menos legible.

Opciones para controlar el uso de RAM del proceso de actualización

-M, --ram=<MB>

El evaluador de consultas intentará mantener su superficie total de memoria por debajo de este valor. (Sin embargo, para bases de datos de gran tamaño es posible que el umbral se interrumpa mediante asignaciones de memoria respaldadas por archivos, que se pueden intercambiar al disco en caso de presión de memoria.)

El valor debe ser de al menos 2048 MB; los valores más pequeños se redondean de forma transparente hacia arriba.

Opciones comunes

-h, --help

Muestra este texto de ayuda.

-J=<opt>

[Avanzado] Asigna la opción a la JVM que ejecuta el comando.

(Ten en cuenta que las opciones que contienen espacios no se administrarán correctamente).

-v, --verbose

Aumenta incrementalmente el número de mensajes de progreso impresos.

-q, --quiet

Reduce incrementalmente el número de mensajes de progreso impresos.

--verbosity=<level>

[Avanzado] Establece explícitamente el nivel de detalle en errores, advertencias, progreso, progreso+, progreso++, progreso+++. Invalida -v y -q.

--logdir=<dir>

[Avanzado] Escribe registros detallados en uno o varios archivos del directorio especificado, con nombres generados que incluyen marcas de tiempo y el nombre del subcomando en ejecución.

(Para escribir un archivo de registro con un nombre sobre el que tienes control total, proporciona --log-to-stderr y redirige stderr como quieras).

--common-caches=<dir>

[Avanzado] Controla la ubicación de los datos en caché del disco que se conservarán entre varias ejecuciones de la CLI, como paquetes QL descargados y planes de consulta compilada. Si no se define explícitamente, se toma como predeterminado un directorio denominado .codeql en el directorio principal del usuario, que se creará en caso de que no exista.

Disponible desde la versión v2.15.2.