Re: ActionLoop 1.0.2 with versioning and support for "more"...
Done. Check the PR -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Carlos Santana To: dev@openwhisk.apache.org Subject: Re: ActionLoop 1.0.2 with versioning and support for "more"... Date: Wednesday, February 27, 2019 11:04 PM I like the idea of using the major digit like a Dave suggested actionloop-v2:tag it matches the other runtimes like nodejs-v8:tag and nodejs-v10:tag - Carlos Santana @csantanapr > On Feb 27, 2019, at 3:14 PM, Michele Sciabarra wrote: > > The reason is to distinguish when there are significant changes. The runtime > is now built statically but the old one was not so if you want to use in an > alpine images you have to use this version. I do not plan to change the name > all the time only when there are significant changes, and should be rare. > Using a v2 is fine for me. > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: David P Grove > To: dev@openwhisk.apache.org > Subject: Re: ActionLoop 1.0.2 with versioning and support for "more"... > Date: Wednesday, February 27, 2019 8:18 PM > > "Michele Sciabarra" wrote on 02/27/2019 02:04:19 > PM: >> >> First and before all, I changed the name to actionloop-v1.0.2 so any >> build depending on it can retrieve the right version... (more >> version, if there is any potentially breaking change, will use a >> different name). >> > > I understand the desire to change the name. I don't like embedding a full > semantic version into the image name (as opposed to the image tag). > Perhaps actionloop-v2 is an acceptable compromise? > > We should be doing proper Apache releases of our runtimes and getting the > semvar into the image tags, not the image names. > > --dave >
Re: ActionLoop 1.0.2 with versioning and support for "more"...
I like the idea of using the major digit like a Dave suggested actionloop-v2:tag it matches the other runtimes like nodejs-v8:tag and nodejs-v10:tag - Carlos Santana @csantanapr > On Feb 27, 2019, at 3:14 PM, Michele Sciabarra wrote: > > The reason is to distinguish when there are significant changes. The runtime > is now built statically but the old one was not so if you want to use in an > alpine images you have to use this version. I do not plan to change the name > all the time only when there are significant changes, and should be rare. > Using a v2 is fine for me. > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: David P Grove > To: dev@openwhisk.apache.org > Subject: Re: ActionLoop 1.0.2 with versioning and support for "more"... > Date: Wednesday, February 27, 2019 8:18 PM > > "Michele Sciabarra" wrote on 02/27/2019 02:04:19 > PM: >> >> First and before all, I changed the name to actionloop-v1.0.2 so any >> build depending on it can retrieve the right version... (more >> version, if there is any potentially breaking change, will use a >> different name). >> > > I understand the desire to change the name. I don't like embedding a full > semantic version into the image name (as opposed to the image tag). > Perhaps actionloop-v2 is an acceptable compromise? > > We should be doing proper Apache releases of our runtimes and getting the > semvar into the image tags, not the image names. > > --dave >
Re: ActionLoop 1.0.2 with versioning and support for "more"...
"Michele Sciabarra" wrote on 02/27/2019 02:04:19 PM: > > First and before all, I changed the name to actionloop-v1.0.2 so any > build depending on it can retrieve the right version... (more > version, if there is any potentially breaking change, will use a > different name). > I understand the desire to change the name. I don't like embedding a full semantic version into the image name (as opposed to the image tag). Perhaps actionloop-v2 is an acceptable compromise? We should be doing proper Apache releases of our runtimes and getting the semvar into the image tags, not the image names. --dave
ActionLoop 1.0.2 with versioning and support for "more"...
Hello all, I just submitted the PR for an update to ActionLoop to support
"more"...
First and before all, I changed the name to actionloop-v1.0.2 so any build
depending on it can retrieve the right version... (more version, if there is
any potentially breaking change, will use a different name).
Then the changes.
Now the binary is built statically, so it works in "more" Docker images (most
notably it should work also in Alpine images). The current actionloop depends
on GLIBC so, for example, I had to use an ubuntu based images for Python3.7
instead of an Alpine one... This now changed.
The other important change is a behviour in compilation and type detection. A
script is detected as executable if it starts with '#!' (before an exectuable
had to be an elf binary), and the "precompilation" feature now gather all the
files in the "bin" folder. In short those changes let me to build a prototype
of the upcoming ActionLoop for java.
Now you can creating an action from a java source (and it will be compiled on
the fly):
$ wsk action create test/hello-java main.java --docker actionloop/java-v8
$ wsk action invoke test/hello-java -r
{
"greeting": "Hello stranger!"
}
And also precompilation works:
$ docker run -i actionloop/java-v8 -compile main main.zip
$ wsk action update test/hello-java main.zip --docker actionloop/java-v8
ok: updated action test/hello-java
$ wsk action invoke test/hello-java -r
{
"greeting": "Hello stranger!"
}
For the curious, here is what is in the main.zip:
$ unzip -l main.zip
exec
classes/exec__.class
classes/main.class
Here exec is not a binary (as it used to be) but a shell script that launches
the java application, compiled in the main.class with added a launcher
implementing the actionloop protocol.
PS no, the runtime for java is not yet ready there is a lot of more work to do,
I needed those changes in the base runtime to move forward. And I have to help
finish the rust runtime first...
--
Michele Sciabarra
mich...@sciabarra.com
