fn init --help
...
choose an existing runtime - .js, .cs, .java, .go, .rb, .py, .php, .rs, .fs
...

Golang (.go vs. go) does not provide a good example but...

fn init --runtime=python

        ______
       / ____/___
      / /_  / __ \
     / __/ / / / /
    /_/   /_/ /_/

Runtime: python
func.yaml created.

I think this may be addressable with flipping rt from key to value:

for _,rt := range fileExtToRuntime {
	fnInitRuntimes = append(fnInitRuntimes, rt)
}

So:

strings.Join(fnInitRuntimes, ", ")

Produces:

rust, dotnet, java, node, python, php, go, ruby, dotnet

And perhaps (once supported), dedup'ing C#, F# etc. to just one dotnet

curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
If you are just upgrading your functions cli client, ignore this and wait a few seconds.
You may press Ctrl+C now to abort this process.

(wait for download to start) 
(hit Ctrl+C)

fn 
[1]    4299 bus error (core dumped)  fn

installer should download to a temp location and move over fn when complete

shouldn't we be able to override the default which is currentdir? (or maybe it's name)

Initially Java .

fn init --runtime java 
cat func.yaml
...
format: http
...

To Reproduce the problem

1. Start docker registry with specified port number

$ docker run -d -p 5000:5000 --restart always --name registry registry:2

2. Execute fn deploy with registry option

$ fn deploy --app myapp --registry localhost:5000/mpppk
Deploying fn-test to app: myapp at path: /fn-test
Bumped to version 0.0.9
Building image localhost:5000/mpppk/fn-test:0.0.9
Sending build context to Docker daemon 17.41kB
Step 1/8 : FROM funcy/go:dev as build-stage
 ---> 4cccab7fc828
Step 2/8 : WORKDIR /function
 ---> Using cache
 ---> 6272ca9b2116
Step 3/8 : ADD . /go/src/func/
 ---> fde238a0c90c
Step 4/8 : RUN cd /go/src/func/ && go build -o func
 ---> Running in 7a49e0221081
 ---> 589dbab01ebf
Removing intermediate container 7a49e0221081
Step 5/8 : FROM funcy/go
 ---> 573e8a7edc05
Step 6/8 : WORKDIR /function
 ---> Using cache
 ---> 59311302641b
Step 7/8 : COPY --from=build-stage /go/src/func/func /function/
 ---> Using cache
 ---> 8314a0b63571
Step 8/8 : ENTRYPOINT ./func
 ---> Using cache
 ---> ff1d0c216a7e
Successfully built ff1d0c216a7e
Successfully tagged localhost:5000/mpppk/fn-test:0.0.9
ERROR: image name must have an owner and name, eg: username/myfunc. Be sure to set FN_REGISTRY env var or pass in --registry.

Possible Fix

Fix func validateImageName in common.go.
(I'll send a pull request soon.)

similar too heroku logs --tail ..

would work for both functions and apps (as apps functionality gets released)

fn apps config and fn routes config support both set and unset but lack get or list.
Currently the only way to find out a configuration value is to use inspect which returns a JSON document with more than just the user specified configuration key/value pairs.

I suggest adding a get command to both apps and routes config command which would take the key name and return the associated value.

$ fn apps config set myapp loglevel debug
myapp updated loglevel with debug
$ fn apps config get myapp loglevel
debug

For symmetry with other commands that have a list command we should also add list and l to both apps and routes config. This would just return a list of key/value pairs in plain text, like fn apps list. Not sure what the delimiter should be but if we used = then it would look like the following:

$ fn apps config set myapp loglevel debug
myapp updated loglevel with debug
$ fn apps config set myapp timeout 400
myapp updated timeout with 400
$ fn apps config list myapp
loglevel=debug
timeout=400

If path: is ommitted from func.yaml, and you have one function nested within another, fn deploy deploys both parent and child function, but binds the parent image to the child image's path as well as the parent path.

If path is specified in the parent func.yaml then only the parent is deployed by func.yaml

Expectation:

Fn either only deploys the current function to the correct path, or it deploys parent and child to the correct paths

Example:

/t/deployex ❯❯❯ tree
.
├── Dockerfile
├── func.yaml
└── reverse
    ├── Dockerfile
    └── func.yaml

Parent:

cat ./func.yaml
name: parent
version: 0.0.11
runtime: base
memory: 128
format: default
timeout: 30

cat Dockerfile
FROM funcy/base
ENTRYPOINT 'cat'

Child

cat ./reverse/func.yaml
name: reverse
version: 0.0.4
runtime: base
memory: 128
format: default
timeout: 30

cat reverse/Dockerfile
FROM funcy/base
ENTRYPOINT 'rev'

Deploy app:

export FN_REGISTRY=foo
fn create app foo
fn deploy --local foo 

fn deploy --local foo
bumping version in func file at:  /tmp/deployex/func.yaml
Bumped to version 0.0.12
Building image fnflowexample/parent:0.0.12
Sending build context to Docker daemon  5.632kB
Step 1/2 : FROM funcy/base
 ---> 88c0b9e0dd0b
Step 2/2 : ENTRYPOINT 'cat'
 ---> Using cache
 ---> 60e7a4897f9c
Successfully built 60e7a4897f9c
Successfully tagged fnflowexample/parent:0.0.12
Updating route /deployex using image fnflowexample/parent:0.0.12...
bumping version in func file at:  /tmp/deployex/func.yaml
Bumped to version 0.0.13
Building image fnflowexample/parent:0.0.13
Sending build context to Docker daemon  5.632kB
Step 1/2 : FROM funcy/base
 ---> 88c0b9e0dd0b
Step 2/2 : ENTRYPOINT 'cat'
 ---> Using cache
 ---> 60e7a4897f9c
Successfully built 60e7a4897f9c
Successfully tagged fnflowexample/parent:0.0.13
Updating route /reverse using image fnflowexample/parent:0.0.13...
``

After this both `/parent` and `/reverse` are attached to the parent's image. 

The following runtimes are using local builds and should be using multi-stage builds:

• php
• rust
• dotnet?

Use improved build command to reduce binary size:

go build -ldflags "-s -w"

For each platform binary size goes down for at least 3-5 megs

Arguably, I think (at least) during fn init we should create .dockerignore that includes func.yaml.

Without this, every iteration of fn deploy for an app that hasn't changed, I have lost the benefits of Docker caching, and must always create a separate layer.

While users who use repo per function may not experience this, if I have organized myself into a monolith of many functions per repo, I will probably have a make deploy that will take more time than necessary and introduce more layers, when all that was required was a tag.

Arguably it would be nice to implicitly add func.yaml to the ignore list even if there exists a user managed .dockerignore. However that may be too surprising, instead we could do a check and warn if it's not present.

So, when developer wants to test function, he uses test.json as a test contract

{
  "tests": [
    {
      "input": {
        "body": {
          "name": "Johnny"
        }
      },
      "output": {
        "body": {
          "message": "Hello Johnny"
        }
      }
    }
  ]
}

This proposal addressing certain cases when secrets needs to be ignored by VCS, for particular instance:
i want to store my API keys away from Git but want to keep test.json in-tree

So, proposing one for test contract attribute in addition that what already we have:

• from_os or from_env (just need certain name that does not collide with env attribute of test.

@treeder @carimura @hibooboo2

for now forces user to specify app so that app can act as namespace .. ie myapp-dev, myapp-prod.

The following func.yaml seems to have broken somewhere between 0.3.63 and 0.3.69:

name: fn-test/test-4
version: 0.0.1
runtime: java

path: /test
timeout: 450

build:
  - mvn package dependency:copy-dependencies -DincludeScope=runtime -DskipTests=true -Dmdep.prependGroupId=true -DoutputDirectory=target

cmd: com.fnproject.fn.integration.ExerciseEverything::handleRequest

specifically, the "build" commands are not run prior to packaging the content with a supplied Dockerfile. Is this accidental? This was pretty useful behaviour for runtimes like the Java one where it's often the case that a function may be a module of a larger project.

need to figure out what api we want for this. we could bake into cli just getting all results or add pagination parameters to cli commands. in any case, we're going to start showing just the first 30 results here pretty soon in the cli, and we seem to be pushing the cli on people, so should probably have something for lack of ui / other tools.

Not sure if this is a bug or behaving as designed, but it's non-obvious:

I've a func.yaml that specifies a build: command sequence. Somewhat surprisingly, I'm seeing a build running twice - the mvn invocation (this instance is using the java runtime) runs locally (which works), then attempts to run a second time inside the scope of the dockerbuild (which in this case, will fail).

I can work around this by supplying a custom Dockerfile, but - is this intended behaviour?

(Incidentally it took a while to spot what was going on because the first mvn build was hidden by #5.)

From @tteggel:

If I have 4 funcs

app.yaml
a/create/func.yaml
a/delete/func.yaml
b/create/func.yaml
b/delete/func.yaml

with no routes in the func.yaml then I get routes for /create and /delete pointing to b's images

see fnproject/fn#350 for context. certain languages use more memory than others, it would be nice to default to a higher value for them in fn init

See: go-swagger/go-swagger#1170

with cli 0.4.4

version: 0.0.6
runtime: java
cmd: com.example.fn.HelloFunction::handleRequest
build_image: ""
run_image: ""
expects:
  config: []

Deploy

fn routes inspect travel /book                                    master ◼
{
	"format": "http",
	"idle_timeout": 30,
	"image": "demo/book:0.0.7",
	"memory": 128,
	"path": "/book",
	"timeout": 30,
	"type": "sync"
}

then an update to the format sets an invalid docker image:

fn routes update travel book --format http                        master ◼
travel /book updated

fn routes inspect travel /book                                    master ◼
{
	"format": "http",
	"idle_timeout": 30,
	"image": "demo/.:0.0.7",
	"memory": 128,
	"path": "/book",
	"timeout": 30,
	"type": "sync"
}

Image is now invalid demo/.:0.0.7

On systems where the SELinux security policies are enforced, fn start is not able to mount the current directory as a writable volume in the spawned Fn Docker container (this causes Fn to be unable to write to the default database), nor to run any container through the mount of the local docker socket.

The docker-in-docker solution seems to be working but it can't access local images deployed with fn deploy --local.

As OEL 7.x and other enterprise Linux systems use SELinux, we need to find a solution that lets us run Fn seamlessly on enforcing systems.

Actual:

fn help init
...
   --runtime value           choose an existing runtime - .go, .rb, .php, .rs, .js, .py, .cs, .fs, .java
...

Expected:
List of runtimes from https://github.com/fnproject/cli/blob/master/langs/base.go#L17

mkdir nodefn
cd nodefn
fn init --runtime node

func.yaml has been created but func.js not.

The CLI should generate boilerplate with a basic example on fn init (as per java) for go and python.

• Should honor "FDK_VERSION" env option (or CLI option) to select FDK version explicitly
• Should get latest version remotely and fix this in the func.yaml/code if not set
• Should include a basic "hello world" example
• Should include a fn test

Fn release scripts pushing new image fnproject/fnserver, but CLI still points to fnproject/functions.

The Problem

Currently LanguageHelpers are part of the CLI source code. This means that support for a given language must be hardcoded in, forcing users to re-download the CLI every time a new language is added, and also not allowing people to provide support for their own language of choice.

Proposed solution

Implement the language helpers as a docker image-based plugin, downloaded/run upon calling fn init or fn build. This has a number of benefits:

• New languages can be added without updates to the CLI source.
• Users can provide support for their own languages.
• Language support can be written in any language (no need for contributors to learn Go!)
• Users can add support for a language for personal use without needing the blessing of the Fn team.
• Slightly simplifies the CLI codebase (both init.go and common.go will become slightly less complex, and the langs directory is entirely removed.

Details

Currently the plan is as follows:

• Each LangHelper now takes the form of a docker image.
• When fn init or fn build is called, the CLI will run the container from that image, and retrieve the information required as a JSON encoded struct.
• The container will also produce any side effects produced as necessary (boilerplate generation, and prebuild stages
• The CLI will ascertain which docker image is required in one of two ways. Either, the --runtime flag (or the runtime field in the func.yaml will directly refer to a docker image, in which case that image will be pulled from Dockerhub - this is what allows users to use non-official images for their projects.
• If the --runtime flag does not refer to a docker image (i.e. it does not contain a /), then the image name required is decided dynamically using a naming convention that is yet to be completely decided, but something akin to fnproject/fn-langhelper-$RUNTIME:latest.

Progress

I have begun work on this already, and am approaching a presentable proof of concept in the form of a docker plugin for the java LangHelper; discussion and feedback is greatly welcomed.

tl;dr

To provide an easy, flexible, and pluggable way for developers and users to add support for a given language, without updating the CLI source code.

fn init xxx --runtime yyy will fails because the 'yyy' runtime doesn't exist but still, an empty 'xxx' dir will be created.

I'm trying to create a route using the command fn routes create hello-async-app hello1

However this gives the message ERROR: no image specified.

If I type fn routes create --help, the --image parameter is described as an "option", which implies it is optional. Is it now always mandatory? If so should the online help say this?

If I specify an image name (as given in the example at https://github.com/fnproject/fn/blob/master/docs/definitions.md):

fn routes create myapp /path --config k1=v1 --config k2=v2 --image fnproject/hello

This fails with

ERROR: image name must have a tag

Java and Python have a version scheme as part of the base runtime string value (https://github.com/fnproject/cli/pull/118/files#diff-a3639713bb27239dd39d24f7d2fc9678R12) and similar things will probably happen in other languages as we go. I think we should figure out a better way to deal with versions, for instance using tags like docker, eg: python:2 or java:9. The runtime's would always be the same, ie: python or java, and the lang helper can deal with the versions during builds. And reject versions it doesn't support.

Re: #118

At this moment CLI doesn't do that at its best but should be.

This appears to be annoying very often.
Assume developer have 10+ routes and in order to dismiss app he needs to go through all routes before deleting an app.
So having --force flag (default to False) will make UX way more better.

I get the following error when running from the Docker quickstart terminal on windows 10 -

fn.exe start
docker: Error response from daemon: invalid bind mount spec "C:\\Program Files\\Git/data:/app/data": invalid mode: /app/data.

On Windows

mkdir helloNode && cd helloNode
fn init --runtime node
fn deploy ...
fn call ...

Actual:
invalid argument "yanongena/helloNode:0.0.1" for t: invalid reference format: repository name must be lowercase

Expeced:
Hello World!

> fn --help
fn 0.4.11

Fn command line tool

USAGE:
   Check the docs at https://github.com/fnproject/fn/blob/master/fn/README.md

ENVIRONMENT VARIABLES:
...

The link to README.md is broken.
Of course the CLI itself provides enough information to actually get started anyway, so it's probably just a cosmetic issue.

After running fn start in the foreground, Ctrl-C'ing the process sometimes stops the functions container and sometimes leaves it running. Working with new users I've seen them interrupting fn start and then reissuing the command only to be told the container 'functions' is already running. To avoid making casual users learn Docker, I suggest a few enhancements:

1. Ctrl-C/SIGINT to fn start should shut down the functions container
2. If someone issues fn start and the functions container is already running it should fail with an appropriate user friendly error message.
3. Either add an argument to fn start like -f(orce) or add fn restart to shut down the current functions container and start a new one. I think "restart" is more explicit and would be the advice provided when the user tries to use "start" when a functions container is already running.

--runtime help list file extend name like ".go",".java", is not runtime correct name,
other thing help information have no version information , like "python2.7", "python3.6", "node" ,"lambda-node-4" , it's not friendly useful .

may be we can use registry model, let every XXXLangHelper reg self with runtime name

When issuing:
fn routes create myapp /hello -i shaunsmith/hello-node:0.0.8
The result is:

/hello created with shaunsmith/:0.0.1

The image name is missing and the tag is incorrect.

fn routes list myapp confirms the route is setup wrong:

path		image				endpoint
/hello		shaunsmith/:0.0.1		localhost:8080/r/myapp/hello

This issue leads to image malforming.
Deploying

fn deploy functions-hub --registry denismakogon

Inspecing

fn routes i functions-hub /env
{
	"format": "default",
	"idle_timeout": 30,
	"image": "denismakogon:sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 30,
	"type": "sync"
}

Updating with func.yaml

fn routes u functions-hub /env
functions-hub /env updated

Inspecting one more time

fn routes i functions-hub /env
{
	"format": "default",
	"idle_timeout": 30,
	"image": "sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 30,
	"type": "sync"
}

see:

❯ fn routes i myapp draw
{
	"format": "default",
	"idle_timeout": 30,
	"image": "wcr.io/iron/draw:0.1.234",
	"memory": 128,
	"path": "/draw",
	"timeout": 120,
	"type": "sync"
}

~/workspace/vista/services/draw master* ⇡
❯ fn routes update myapp draw --type sync
myapp /draw updated

~/workspace/vista/services/draw master* ⇡
❯ fn routes i myapp draw
{
	"format": "default",
	"idle_timeout": 30,
	"image": "wcr.io/iron/draw:0.1.234",
	"memory": 128,
	"path": "/draw",
	"timeout": 30,
	"type": "sync"
}

~/workspace/vista/services/draw master* ⇡
❯ cat func.yaml
name: draw
version: 0.1.234
timeout: 120

CLI needs newer fn_go and its features like call.error thing (indicates why the particular call failed).

Existing route

fn routes i functions-hub /env
{
	"format": "http",
	"idle_timeout": 30,
	"image": "sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 50,
	"type": "sync"
}

Updating route:

fn routes u --ignore-fn-file --idle-timeout 50s functions-hub /env
functions-hub /env updated

Inspecting updated route

fn routes i functions-hub /env
{
	"format": "default",
	"idle_timeout": 50,
	"image": "sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 30,
	"type": "sync"
}

FN server works as expected:

fn routes i functions-hub /env
{
	"format": "default",
	"idle_timeout": 50,
	"image": "sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 30,
	"type": "sync"
}

curl -X PATCH localhost:8080/v1/apps/functions-hub/routes/env -d '{"route":{"timeout":50}}'

fn routes i functions-hub /env
{
	"format": "default",
	"idle_timeout": 50,
	"image": "sample:0.0.4",
	"memory": 128,
	"path": "/env",
	"timeout": 50,
	"type": "sync"
}

The default port is 8080, how to change the port of Fn Server when execute fn start, thanks.

CLI version 0.3.72

Fn API allows to filter calls by app and route but CLI ignores path.

fn calls list --help
NAME:
   fn calls list - list all calls for specific app / route route is optional

USAGE:
   fn calls list <app> [route]
Deniss-MBP-2:cli denismakogon$ fn calls list application /env
ID: 01BWK116ZNY7WNT00000000000
App: application
Route: /traceback
Created At: 2017-10-16T19:42:23.605+03:00
Started At: 2017-10-16T19:42:23.605+03:00
Completed At: 2017-10-16T19:42:23.606+03:00
Status: success

ID: 01BWK115YHY7WNP00000000000
App: application
Route: /env
Created At: 2017-10-16T19:42:22.545+03:00
Started At: 2017-10-16T19:42:22.728+03:00
Completed At: 2017-10-16T19:42:23.587+03:00
Status: success

1. Python
2. Go
3. Lambda node
4. Ruby
5. PHP