[ci breaking-change] feat: detect breaking jetstream images#3063
[ci breaking-change] feat: detect breaking jetstream images#3063
Conversation
4d16cbc to
cad8231
Compare
cad8231 to
dcaf0cc
Compare
dcaf0cc to
63de321
Compare
| run: docker build . -t jetstream:latest -t jetstream:breaking | ||
| - name: Push Docker image to GAR | ||
| uses: mozilla-it/deploy-actions/docker-push@v3 | ||
| with: |
There was a problem hiding this comment.
Not sure if you already checked if publishing the two tags works? I had some problems with the newer version of docker-push where only one tagged image could be published at a time resulting in multiple tasks: https://github.com/mozilla/lookml-generator/blob/efc47dfa6a0670028dd9bb3bd61fb2f90de9041a/.github/workflows/build-and-deploy.yml#L289-L307
There was a problem hiding this comment.
Ah good to know, thanks! I actually had it doing this separately at first but then was hoping it would work this way and was about to test it. I'll test anyway, but will probably have to split it out.
There was a problem hiding this comment.
Ok confirmed that this does not work, I'll split it out.
| if breaking_image: | ||
| breaking_time = breaking_image.upload_time | ||
| # see note below about mypy ignore here | ||
| if last_updated and last_updated < breaking_time: # type: ignore |
There was a problem hiding this comment.
I guess in theory if a breaking image is pushed around the time an analysis run is triggered/running (which uses the previous image version), the created tables for new experiments might end up having a creation timestamp < breaking_time. I don't expect that this is likely to happen, so probably not worth thinking too much about it.
There was a problem hiding this comment.
Hm I think you mean this scenario?
- analysis starts but has not written to any tables
- breaking image is pushed
- analysis writes to a table
This is ok because a subsequent run should pick up the breaking image using the existing logic in_image_for_date(breaking image upload time is the latest image at the time of the table creation). In the other direction, if the breaking image is pushed just after table creation, then this check handles that (tables created before breaking image upload, so use the breaking image).
Or am I misunderstanding your scenario?
There was a problem hiding this comment.
Yeah, that's the scenario I was thinking of. I was ignoring the _image_for_date, but makes sense. This shouldn't be a concern then
7778999 to
90bfc73
Compare
breakingtag that are newer than otherwise would've been retrieved for an experimentbreakingtag to the image if requestedfixes #3062