ci(jenkins): enable pipeline #8
Conversation
v1v
requested review from
ElWPenn,
ezimuel,
kuisathaverat,
mdelapenya and
philkra
| RUN apk --no-cache add build-base autoconf curl-dev | ||
|
|
||
| WORKDIR /app/src/ext | ||
|
|
There was a problem hiding this comment.
we need to copy the extension to /app/src/ext first in order compile "it" on L:7
COPY src/ext /app/src/ext
There was a problem hiding this comment.
This is not required since this particular docker image is only for the environmental requirements.
The docker container should mount the volume and therefore the CMD directive will run those commands using the mounted volume.
Dockerfile
Outdated
| CMD phpize \ | ||
| && ./configure --enable-elasticapm \ | ||
| && make clean \ | ||
| && make \ |
There was a problem hiding this comment.
we should add && make test \
There was a problem hiding this comment.
I was not sure whether either make or make install might call the command make test as a dependent goal. I'll put it explicitly, now, and archive the test output
There was a problem hiding this comment.
I've decided to change the approach:
- The default behavior in the docker container will be the build goal, aka
make - Then it is overridden when passing the cmd argument for instance:
The reason is to help to categorize those commands in stages in the pipeline and visualise them easily in the CI.
… Besides, some readme details about using the docker container
| ENV REPORT_EXIT_STATUS=1 | ||
| ENV TEST_PHP_DETAILED=1 | ||
| ENV NO_INTERACTION=1 | ||
| ENV TEST_PHP_JUNIT=/app/junit.xml |
There was a problem hiding this comment.
This env variable and the above ones are required when running the make test to help with:
- More detailed info
- Report the exit
- Avoid interactive when a test failure to send an email to the PHP community
- Generate junit output in a file to be consumed within the Jenkins pipeline.
…s, and therefore the user is also required
|
I'll proceed to merge this PR and we can iterate later on with some follow ups :) |
Tasks
Further details.
Docker container will run the make default goal, then the CI pipeline will orchestrate the remaining goals in some sequential stages to reuse the same workspace. Remaining goals are:
The only output which it's generated at the moment, besides the log output, is the test output in JUnit format to be digested by the CI pipeline in Jenkins (see the below screenshots).
The main reason to use docker is to avoid setting up the local environment and be deterministic about what are the tools required to be used for building/testing and installing the library. It's defined once and the CI build can be easily reproduced locally with docker.
e2e tests