openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <>
Subject Re: Moving out runtime images and tests
Date Tue, 12 Sep 2017 20:02:48 GMT
Sounds all sensible to me.

To 1: Sounds like the right thing to do, if versions are common enough? Like major bumps could
probably use different repos but I guess we can just try and find out what works. As a starter,
the list you posted sounds sensible to me!

2. By Integration Tests I meant: Do the repos need to standup a whole OpenWhisk system and
then run integrations tests or can we get away with just unit tests. I think, the best would
be the latter since its the most agile but we might not be quite there yet. Again something
we should just try and will discover on the way I think!

3. Yep, it's probably just build and push the images on each commit just like we do for master.

One more thing (hehe): Do we support independent tags of runtime images vs. the deployed system?
Today we use the same tag that we use to deploy the system to pull the runtime images. There
might be something left to do here like: Do we need a specific version for each runtime (most
flexible) or can we get away with just using latest for each runtime (easiest to maintain).
Versioning might be needed to be able to make breaking changes but still pin versions and
to keep production systems stable that way (otherwise they might pull an incompatible image
while in action). Thinking about it: We need independent versioning per runtime.

Am 12. September 2017 um 21:56 schrieb Rodric Rabbah <>:

+1 good points Tyson.


On Sep 12, 2017, at 1:25 PM, Tyson Norris <> wrote:

+1 in general

Tasks we'd need to do:
1. Setup a repo per runtime.

Maybe repo per runtime-type, instead of literally each runtime - specifically names like:
openwhisk-action-nodejs, openwhisk-action-java, openwhisk-action-dockerskeleton, openwhisk-action-php,
openwhisk-action-python, openwhisk-action-swift
(Since each type should share much of the same tests, I think.)

2. Move the runtime build + tests there (testwise I would rather copy and own some dependencies
than trying to go DRY. The current setup for dependent repos needs quite some cleanup and
is super hard to maintain for updates in the main repo). We can discuss if we need Integration
Tests for each of the runtimes or if the "unit" tests we have are sufficient here.

We can DRY it *later* if wanted by releasing mvn artifacts of test base classes (or all of
tests) from core, or something like that, but until that is implemented, agree that copying
is better.

By “Integration Tests” do you mean to run as part of core tests? I think something minimal
would be good like “test that at least nodejs runtime works” (e.g. health check), but
not “test every runtime as part of core integration tests"

3. Implement a release process for the runtime images to Dockerhub.

This should be the same as the release process for core images right?


The runtimes update fairly rarely so I wouldn't really bother with too strict of a versioning
there, at least not for the first shot. Process wise it does seem straightforwardly doable.

What do you think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message