Commit ab33fb32 authored by Devin OKelly's avatar Devin OKelly
Browse files

Comment up gitlab-ci.yml

parent b9eb5321
# before_script
# Set up an environment
# Later stage: Use that environment.
#
# after_script
# This file is a template, and might need editing before it works on your project.
# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml
# This is a sample GitLab CI/CD configuration file that should run without any modifications.
# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
# it uses echo commands to simulate the pipeline execution.
......@@ -27,61 +7,111 @@
#
# For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages
stages: # List of stages for jobs, and their order of execution
stages: # List of stages for jobs, and their order of execution. Note that a stage MUST be listed here if it is referenced.
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
# These defaults will run before and after every single script, unless otherwise overridden.
default:
before_script:
- echo "Execute this `before_script` BEFORE all jobs by default."
- echo "loading python"
after_script:
- echo "Execute this `after_script` AFTER all jobs by default."
# This job will run with the default before-script and will create an artifact which is passed to
# a later job, The artifact will also be available to download via GitLab.
build-job:
stage: build
script:
- echo "Compiling the code..."
- mkdir ""./artifacts/""
- echo "codecodecodecode" > ./artifacts/build.txt
- echo "pythonpythonpython" > ./artifacts/build.txt
- echo "Compile complete."
artifacts:
paths:
- ./artifacts/build.txt
# This job will OVERRIDE the default before-script with its own and will create an artifact which is NOT
# passed to a later job (unless a specific needs: relationshio is specified)
# The artifact will also be available to download via GitLab.
build-job-override-beforescript:
stage: build
before_script:
- echo "loading matlab"
script:
- echo "Compiling the code..."
- mkdir ""./artifacts/""
- echo "matlabmatlabmatlab" > ./artifacts/build.txt
- echo "Compile complete."
artifacts:
paths:
- ./artifacts/build.txt
echo-build-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
# TEST STAGE JOBS #
# These will only run once all jobs in the previous ('build') stage are run successfully.
# The exception to this is if the job has allow_failure - see below.
# This test gets passed an artifact from a previous job because `echo-build-job` specifies
# a 'needs:' relationship with `build-job`.
echo-build-job:
stage: test
script:
- echo "The contents of the build file are:"
- cat "./artifacts/build.txt"
needs:
- build-job
unit-test-pass-last: # This job will not run 'always_passes' because the earlier command does not exit with 0.
stage: test # It only starts when the job in the build stage completes successfully.
# This test will always pass, because `always_passes` will always return with exit code 0.
unit-test-only-pass:
stage: test
script:
- bash ./tests/unit/always_fails.sh;
- bash ./tests/unit/always_passes.sh;
# Here a wrapper script (gitlab_test.sh in the tests folder) runs many tests sequentially.
# Note that the GitLab runner running this job will only know about `gitlab_test`'s exit code,
# but will be unaware of any failures inside that wrapper. This has consequences for using other frameworks
# to run your tests (e.g. pytest, MATLAB's included testing capabilities) - make sure that, if the tests
# fail inside that framework, those failures are communicated up to the GitLab runner by exiting with exit code 1.
multi-test-job:
stage: test
script:
- bash ./tests/gitlab_test.sh
# The most basic type of job that can fail - These kinds of tests will not block progression to
# the next stage of the CI pipeline, so can be useful for 'finicky' or 'nice but not necessary' features.
can-fail-job:
stage: test .
script:
- echo "This job should fail, but that shouldn't stop anything."
- exit 1
allow_failure: true
unit-test-fail-last: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
# This job will only run halfway - `always_passes` will successfully run (exit code 0)
# but `always_fails` will predictably fail, halting execution there and causing the job to fail.
unit-test-fail-last:
stage: test
script:
- bash ./tests/unit/always_passes.sh;
- bash ./tests/unit/always_fails.sh;
allow_failure: true
unit-test-only-pass: # This job runs in the test stage.
# This job will fail immediately - `always_passes` will never run because the job fails as soon as any
# of the individual commands fail.
unit-test-pass-last:
stage: test # It only starts when the job in the build stage completes successfully.
script:
- bash ./tests/unit/always_fails.sh;
- bash ./tests/unit/always_passes.sh;
allow_failure: true
multi-test-job:
stage: test
script:
- bash ./tests/gitlab_test.sh
can-fail-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
script:
- echo "This job should fail, but that shouldn't stop anything."
- exit 1
allow_failure: true
# DEPLOY JOBS #
# These only run if all of the jobs in 'test' complete successfully, or are allowed to fail.
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment