mirror/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-02-11 00:40:05 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

all.sh/components: Removed components.sh

Browse Source 
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
This commit is contained in:
Minos Galanakis 2024-08-01 23:24:15 +01:00
parent bb427371e6
commit bd6b98fd40
1 changed files with 0 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
tests/scripts/components.sh
View File

@ -1,63 +0,0 @@
# components.sh
#
# Copyright The Mbed TLS Contributors
# SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later
# This file contains the test components that are executed by all.sh
# The functions below are named as follows:
# * component_XXX: independent components. They can be run in any order.
# * component_check_XXX: quick tests that aren't worth parallelizing.
# * component_build_XXX: build things but don't run them.
# * component_test_XXX: build and test.
# * component_release_XXX: tests that the CI should skip during PR testing.
# * support_XXX: if support_XXX exists and returns false then
# component_XXX is not run by default.
# Each component must start by invoking `msg` with a short informative message.
#
# Warning: due to the way bash detects errors, the failure of a command
# inside 'if' or '!' is not detected. Use the 'not' function instead of '!'.
#
# Each component is executed in a separate shell process. The component
# fails if any command in it returns a non-zero status.
#
# The framework in all.sh performs some cleanup tasks after each component.
# This means that components can assume that the working directory is in a
# cleaned-up state, and don't need to perform the cleanup themselves.
# * Run `make clean`.
# * Restore `include/mbedtls/mbedtls_config.h` from a backup made before running
# the component.
# * Check out `Makefile`, `library/Makefile`, `programs/Makefile`,
# `tests/Makefile` and `programs/fuzz/Makefile` from git.
# This cleans up after an in-tree use of CMake.
#
# The tests are roughly in order from fastest to slowest. This doesn't
# have to be exact, but in general you should add slower tests towards
# the end and fast checks near the beginning.
################################################################
#### Build and test many configurations and targets
################################################################
################################################################
#### Basic checks
################################################################
#
# Test Suites to be executed
#
# The test ordering tries to optimize for the following criteria:
# 1. Catch possible problems early, by running first tests that run quickly
# and/or are more likely to fail than others (eg I use Clang most of the
# time, so start with a GCC build).
# 2. Minimize total running time, by avoiding useless rebuilds
#
# Indicative running times are given for reference.
################################################################
#### Build and test many configurations and targets
################################################################