AP-554: build a UCBLIT-specific Airflow image#1
Conversation
anarchivist
commented
Feb 3, 2026
- I believe all Airflow config options can be passed in as env variables per the configuration documentation.
- This includes a single test called from the build pipeline to ensure there are no import errors in the Airflow dags.
* I believe all Airflow config options can be passed in as env variables per the [configuration documentation](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html). * This includes a single test called from the build pipeline to ensure there are no import errors in the Airflow dags.
awilfox
left a comment
There was a problem hiding this comment.
Looking pretty good. A few things to address.
ff078ce to
0134a53
Compare
awilfox
left a comment
There was a problem hiding this comment.
Looks great to me. r+ after Docker Compose is running properly in CI.
5ea163a to
2a88a9c
Compare
|
I have the build passing. One thing to note - in GHA, the container is running as |
awilfox
left a comment
There was a problem hiding this comment.
Looks good overall. A few questions to think over, then r+.
de7661a to
1d776e9
Compare
5c17118 to
35bbee5
Compare
35bbee5 to
dbd2827
Compare
99d1074 to
4397dff
Compare
|
Okay - v2 separates the docker startup checks from the dag import checks, which don't require a full Airflow deployment to run. Accordingly, it uploads two test result artifacts - one for Docker/Compose-related logs and one for the Python |
7c068cb to
32fc810
Compare
32fc810 to
a59f272
Compare
a59f272 to
0339cb6
Compare
02ff98c to
139cbe5
Compare
we can successfully get unittest output written in the container and copy it out now
cacd207 to
7177b75
Compare
7177b75 to
731c8a6
Compare
all outstanding issues have been fixed
danschmidt5189
left a comment
There was a problem hiding this comment.
Nothing major jumped out, but I am very curious about the intention behind running the test stage in a container while also using docker-compose commands. I have to be missing something there!
|
|
||
| USER airflow | ||
| WORKDIR /home/airflow | ||
| COPY --chown=airflow:0 requirements.txt . |
There was a problem hiding this comment.
Why use the GID "0" rather than "root", as we do everywhere else? We only use IDs when necessary, e.g. at runtime when the given named user doesn't exist in the container.
There was a problem hiding this comment.
This is relates to an Airflow-on-OpenShiftism that I'm trying to keep consistent with upstream. I'm happy to change it if we don't care:
Airflow image is Open-Shift compatible, which means that you can start it with random user ID and the
group id0(root). If you want to run the image with user different than Airflow, you MUST set
GID of the user to0. In case you try to use different group, the entrypoint exits with error.OpenShift randomly assigns UID when it starts the container, but you can utilise this flexible UID
also in case of running the image manually. This might be useful for example in case you want to
mountdagandlogsfolders from host system on Linux, in which case the UID should be set
the same ID as your host user.
There was a problem hiding this comment.
Relatedly, the overly-complex command for airflow-init is pulled mostly from the upstream compose file.
also, clean up the airflow-init container; minor docs fix