kabanero-io / collections Goto Github PK

This project forked from appsody/stacks

Kabanero Collections - This repo will be archived soon.

License: Apache License 2.0

Shell 61.43% JavaScript 11.80% Batchfile 0.34% Dockerfile 5.98% Java 11.57% HTML 3.01% Kotlin 2.96% Python 2.90% Pug 0.01%

collections's People

Contributors

Stargazers

Watchers

collections's Issues

Provide a Hosted IDE - Enhance Kabanero to install Che with Codewind extensions

Kabanero Spring Stack must be based on snowdrop (deviation from appsody)

The Spring stack for Kabanero will be different than the stack used by appsody (to be compatible with RHR support): it must use library versions specified by RHOAR / RHR via the snowdrop bom.

https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.1.6.RELEASE/pom

https://repo1.maven.org/maven2/me/snowdrop/spring-boot-bom/2.1.6.Final/spring-boot-bom-2.1.6.Final.pom

--> Open question with the latter how to resolve dependency constraints between the two without getting the snowdrop release profile, etc. The appsody spring stack uses the spring dependencies as a parent (for plugin versions, too). The snowdrop spring bom doesn't quite work the same way: it isn't safe to use as a parent, it's designed for dependency import, which is incomplete for plugins.

Add extension kabanero build script to process `pipeline trigger` files

A new shell script needs to be generated and included as part of the CI build scripts.
This new script will look for a triggers directory under each of the repo directories, ie incubator/triggers and use the files within that directory to generate a tar.gz file containing the trigger files. It will also add a triggers element to the kabanero-index.yaml file.

Push prerelease images to different docker org

Describe the bug
When generating preview releases we may overwrite existing docker tags.

To Reproduce
Follow the release process with a beta tag.

Expected behavior
Docker images generated from previous releases should not be overwritten when we cut a preview release.

Actual behaviour
Existing docker images may get overwritten.

If applicable please specify:

Collection you are using: Any

Collection build not pushing stack image to registry

Describe the bug
A clear and concise description of what the bug is.

I followed instructions to customize collections and to create release and set all the suggested variables. But when I initialize the appsody project it is not able to find image at the specified registry.

Since all the information about registry is provided, it should be able to push it? If not, we need to document.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Rework Collections versioning

Kabanero Collection Versioning

Definition of terms - current

Stack version - The version associated with an appsody stack
Collection version - The version associated with the base appsody stack the collection is built from
Collections release version - The version of a given GitHub release for the Kabanero Collections repository

Background and issues

Currently Kabanero collection versioning aligns with the version of the Appsody stack a collection is based on. We have identified several issues with this approach currently:

Issue 1

The Collection build scripts will rebuild the docker files associated with each collection during the release process. These Docker images currently use the latest version of their base images.

The Collection release process currently pushes docker images with tags of 0, 0.X, 0.X.Y and latest for each collection.

The current yaml used by Collections to identify the base Docker image only specifies the major and minor versions in the tag, eg, my-image:0.X

When a stack has not had a version update between releases the new Collection release will overwrite the Docker images created on the previous build with the newly generated Docker images that may be using a newer base level image. Anyone using the previous collection release will now pick up the updated images without explicitly requesting them. This is undesirable as users should have control over when they adopt updates.

Issue 2

When updating collection elements outside the base stack (such as pipelines) there is presently no increment for the collection version.

Currently the operator uses the collection version (ie, the version of the base stack, not to be confused with the version of the collection release) to determine where changes are required when migrating to newer collection releases.

When a stack has not had a version increment between collection releases the operator is not able to identify any changes made to the collection and apply the necessary updates to the deployment environment. For example, pipeline updates are not applied to a collection resulting in an inability to build and deploy applications based upon it (the collection).

Issue 3

As Champ I want to version my customized collections. Presently there is no easy way for me to do this.

If I update the collections configuration when the collection is built all the version labels on the container will be updated. This means we can no longer identify the base stack level used to generate the custom collection. This will also require several manual updates and presents ample opportunity for error.

Versioning changes

Under this epic we are proposing the following updates to versioning for collections.

Definition of terms - proposed

Stack version - The version associated with an appsody stack
Collection version - A version independent of the stack version to be incremented when non-stack artifacts are updated (eg, pipelines)
Collections release version - The version of a given GitHub release for the Kabanero Collections repository
Customized collections version - The version given to a customized Collections repository

Add collection version

The existing collection.yaml file will be updated to add a field that identifies the current collection version. Whenever changes are made to a collection this version should be updated.

Maintain provenance of collections via labeling

We will update the docker files of each collection with a label containing the base collection version and base collections release level. This will allow us to determine the collection provenance for any deployed application.

Version all artifacts with release version

All artifacts published during the Collections release process will be tagged with the Collections release version. Every artifact will be updated on each release giving users control over the adoption of updates.

Version customized collections with Customized collections version

If a collections release is generated by a user we will require them to explicitly version the release. All artifacts will be tagged with the user supplied version.

Use explicit patch levels in all collection configuration, allow optional override

We will update all configuration files to identify docker images using an explicit major.minor.patch version. This prevents updates being adopted “accidentally”.

An additional setting can be used to select the use of major.minor version selection. This gives the collection curator and option to have patch level changes automatically pushed out across their organization.

User scenarios

Release version X.Y.Z of Kabanero collections

Collections developer identifies the correct branch of Kabanero-io/Collections to act as the base for the release.

A git tag X.Y.Z is created against the branch.

The git tag is pushed to the Kabanero-io/Collections repository.

Build automation is triggered and for each collection:
- Docker images are built containing labels for the stack version, the collection version and the collection release version
- Docker images are pushed to the image registry with tags: X, X.Y, X.Y.Z and latest
- Collection artifacts are created with version X.Y.Z
- Github release is created with version X.Y.Z

Champ wants to customize Kabanero collections release X.Y.Z (assuming Champ has travis available)

Champ creates a clone of Kabanero collections at the X.Y.Z release tag.

Champ pushes the cloned collections to a GitHub repository.

Champ updates the collections as needed and pushes changes to their Github repository.

Champ creates a git tag A.B.C against his repository

Champ pushes the git tag.

Build automation is triggered and for each collection:
- Docker images are built containing labels for the stack version, the collection version, the collection release version (X.Y.Z) and Champs version (A.B.C)
- Docker images are pushed to the image registry with tags: A, A.B, A.B.C and latest
- Collection artifacts are created with version A.B.C
- Github release is created with version A.B.C

Champ wants to automatically update all applications built on A.B.C with a security fix (assuming travis is available and optional major.minor override is configured on A.B.C)

Champ branches from the A.B.C release tag.

Champ updates the new branch with the security updates.

Champ pushes changes back to GitHub

Champ tags branch A.B.D

Champ pushes tag to Github

Build automation is triggered and for each collection:
- Docker images are built containing labels for the stack version, the collection version, the collection release version (X.Y.Z) and Champs version (A.B.D)
- Docker images are pushed to the image registry with tags: A, A.B, A.B.D and latest
- Collection artifacts are created with version A.B.D
- Github release is created with version A.B.D

An application build is triggered and the application rebuilds using the A.B docker image (now A.B.D and

Champ wants to optionally update all applications built on A.B.C with a security fix (assuming travis is available)

Champ branches from the A.B.C release tag.

Champ updates the new branch with the security updates.

Champ pushes changes back to GitHub

Champ tags branch A.D.C

Champ pushes tag to Github

Build automation is triggered and for each collection:
- Docker images are built containing labels for the stack version, the collection version, the collection release version (X.Y.Z) and Champs version (A.D.C)
- Docker images are pushed to the image registry with tags: A, A.D, A.D.C and latest
- Collection artifacts are created with version A.D.C
- Github release is created with version A.D.C

Existing applications continue to build using the A.B container images.

Applications have to be migrated to the A.D.C version of Champs collections to pick up the fix. (What’s the migration story??)

Need a way to add files (third party jars etc) to application container for different applications

Describe the bug
A clear and concise description of what the bug is.
Need a way by which user have control over copying some of the files needed by application to copy to the container where application is running. These could be third part jar files, some jam option files or any other file needs by the application. This become important when you are migrating existing applications to appsody to be run with kabanero.

When locally developing and testing application using appsody, any files under src/main/resources were transferred to running container under /project/new-app/target/classes so I need a similar way using kabanero stack which isn't currently intuitive to the user.

This limitation was experienced more for Java Micro profile applications but all other collections may have the similar needs.

To Reproduce
Steps to reproduce the behavior:

Any liberty application which may need to access a file at runtime.

Expected behavior
A clear and concise description of what you expected to happen.

Some way to be able to copy files to container, similar to copy command in dockerfile.

Actual behaviour
What is the actual behaviour.

Do not know how to copy files to the container image.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Instructions on creating a Git release for collection

Describe the bug
I have customized Java MicroProfile collection, tested it locally and make updates to my copy of GitHub collection. I understand that I need to create a collection release but when I create a release it has only code. I need to understand what other files need to be added to the release? I probably need to check in the new MicroProfile images to docker hub.

None of the below document has complete list of steps to publish the updated collection so that Kabanero can use this collection instead of the default collection.

https://kabanero.io/docs/ref/general/collection-building.html
https://github.com/kabanero-io/collections
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Need a raw github link to kabanero-index.json collection to add to codewind template

Describe the bug
I can't add the kabanero collection v0.1.2 template to Codewind because it requires a raw github link. Is there a raw link to https://github.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json ?

The existing Appsody extension for Codewind template uses link https://raw.githubusercontent.com/kabanero-io/codewind-appsody-templates/master/devfiles/index.json so I tried to replace github.com with raw.githubusercontent.com and add https://raw.githubusercontent.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json and I got error

Error adding new template source: "https://raw.githubusercontent.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json does not point to a JSON file of the correct form"

To Reproduce
Steps to reproduce the behavior:

In VS Code + Codewind
Under Codewind, Right click on Projects > Manage Template Sources > Add New
Add a URL to kabanero collection https://github.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json

Expected behavior
Need a raw github link to kabanero collection

Actual behaviour
can't find one

Environment Details (please complete the following information):

VS Code + Codewind plugin

If applicable please specify:

CLI version:
Collection you are using: kabanero

Screenshots
add url https://github.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json

Try to add url https://raw.githubusercontent.com/kabanero-io/collections/releases/download/v0.1.2/kabanero-index.json

Additional context
Add any other context about the problem here.

appsody build take too long to complete

The build took approximately 5 minutes to complete with just a simple string update. The reason I think was it try to re-download Maven repos every time a build is triggered. This is a disadvantage comparing to a traditional dev environment where maven repos are only downloaded once.

kabanero-index.json has "Appsody" in displayName

Describe the bug
The generated kabanero-index.json file has "Appsody" in the displayName for all the templates. As this is the kabanero-index file this should really have "Kabanero" in the displayName in order to differentiate between the "Appsody" and "Kabanero" templates/stacks.

Expected behavior
After adding the kabanero-index.json file to Codewind, I would have expected to see some Kabanero templates listed when adding a new project.

Actual behaviour
Don't see any Kabanero project but only see multiple Appsody projects, so cant destinguish which are Appsody and which are Kabanero projects.

default tekton pipeline for appsody stack should include test task

Is your feature request related to a problem? Please describe.
Problem is that I think the default pipeline which includes 2 tasks build and deploy should have a 3rd task that runs the same process as appsody test

Describe the solution you'd like

The task test-task should be first in the pipeline.
This task should use the container appsody stack (ie Dockerfile-stack), this is specified in the .appsody-config.yaml from the git source
For example nodejs:
```
cat .appsody-config.yaml
stack: kabanero/nodejs-express:0.2
```
The working directory should be /project
The command should similar to $APPSODY_INSTALL and $APPSODY_TEST

Describe alternatives you've considered
I have something working for nodejs-express but I hit a few problems.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: csantana-nodejs-express-build-task
spec:
  inputs:
    resources:
      - name: git-source
        type: git
  steps:
    - name: npm-test
      image: kabanero/nodejs-express:0.2
      workingDir: /project
      command:
        - /bin/bash
      args:
        - -c
        - |
          set -e
          cp -a ${inputs.resources.git-source.path}/* $APPSODY_WATCH_DIR
          # perform npm install
          $APPSODY_INSTALL
          # run npm test on project and user-app
          delimiter=" && "
          s=$APPSODY_TEST$delimiter
          array=();
          while [[ $s ]]; do
              array+=( "${s%%"$delimiter"*}" );
              s=${s#*"$delimiter"};
          done;
          for i in "${array[@]}"
          do
            echo executing $i
            $i
          done

Some of the problems I hit:
. hardcoding the image name kabanero/nodejs-express:0.2 this should be from the config file .appsody-config.yaml

. something weird about running $APPSODY_TEST with the value is npm test && npm test -- prefix user-app mocha tries to parse && as argument, so the workaround I did was to parse the variable and execute it

[nodejs-express-test-build-task : npm-test] > [email protected] test /project/user-app
[nodejs-express-test-build-task : npm-test] > mocha "&&" "npm" "test"
[nodejs-express-test-build-task : npm-test] 
[nodejs-express-test-build-task : npm-test] Warning: Cannot find any files matching pattern "&&"
[nodejs-express-test-build-task : npm-test] Warning: Cannot find any files matching pattern "npm"

. I really wanted to avoid to run appsody extract, this takes too much time when using a volume, so I tried to do a softlink to avoid the cp -a, with ln -s /workspace/git-source /project/user-app the files get map correctly, the problem is with node.js when it tries to resolve node dependencies the cd .. get's resolve into /workspace instead of /project
I guess we can add the appsody extract at this stage, and remove it from the build-task

I'm going to look into spring-boot and microprofile appsody stacks to implement the unit test tasks.

Additional context
Tekton should have a way to dynamically specify the image name for step in a task some how, this way we don't need to hardcode kabanero/nodejs-express:0.2

cc @seabaylea

java-spring-boot2 and java-microprofile custom tekton task

I am trying to include an additional mvn test step in my tekton pipeline task. After running the assemble-extract task, the user app is extracted to an external folder. The folder structure is as follows.

/workspace/extracted
Dockerfile
appsody-boot2-pom.xml
java-spring-boot2-build.sh
mvn-stack-settings.xml
mvnw
mvnw.cmd
user-app

I am able to do the mvn test for the stack using mvn test -f appsody-boot2-pom.xml but I cannot do mvn test for the application using the pom.xml in user-app.

My task is as follows

- name: mvn-test
      securityContext:
        privileged: true
      image: kabanero/java-spring-boot2:0.3
      command: ["/bin/bash","-c","cd extracted && mvn test -f appsody-boot2-pom.xml && cd user-app && ls && mvn test"]
      env:
        - name: gitsource
          value: git-source
      volumeMounts:
        - mountPath: /var/lib/containers
          name: varlibcontainers

Below is the error I get.

[INFO] Scanning for projects...Downloading from central: https://repo.maven.apache.org/maven2/dev/appsody/spring-boot2-stack/maven-metadata.xml[ERROR] [ERROR] Some problems were encountered while processing the POMs:[FATAL] Non-resolvable parent POM dev.appsody:spring-boot2-stack:[0.3, 0.4) for dev.appsody:application:0.0.1-SNAPSHOT: No versions matched the requested parent version range '[0.3, 0.4)' and 'parent.relativePath' points at no local POM @ line 6, column 11 @ [ERROR] The build could not read 1 project -> [Help 1][ERROR] [ERROR] The project dev.appsody:application:0.0.1-SNAPSHOT (/workspace/extracted/user-app/pom.xml) has 1 error[ERROR] Non-resolvable parent POM dev.appsody:spring-boot2-stack:[0.3, 0.4) for dev.appsody:application:0.0.1-SNAPSHOT: No versions matched the requested parent version range '[0.3, 0.4)' and 'parent.relativePath' points at no local POM @ line 6, column 11 -> [Help 2][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

It fails in the same way for microprofile too.

index.yaml contains stacks that are not supported in Kabanero

Describe the bug
The index.yaml that is contained within the git repository contains collections that are not supported in Kabanero. This needs to contain only those collections that are supported.

Delays seeing updates in GIT and Kabanero re: collections

Describe the bug
A clear and concise description of what the bug is.
After a change is made to kabanero-index.yaml or an update is made to a Kabanero Collections object there is sometimes as much as a 2-3 minute delay to see the change reflected when reading either the kabanero-index.yaml or displaying the collections object in K8S

All of the above can be tested using the Kabanero CLI

To Reproduce
Steps to reproduce the behavior:

Go to kabanero-index.yaml remove a collection or change a version number and read the collection with a REST call.

Change the desiredState of a Kab collection object to active or inactive and see how long it takes to show up

Expected behavior
A clear and concise description of what you expected to happen.
Expect to see these changes almost immediately

Actual behaviour
What is the actual behaviour.
Sometimes delays of almost 2-3 minutes to see the changes in GIT or Kabanero

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version: 0.3.0-alpha.1
Collection you are using: my owned cloned version of https://github.com/kabanero-io/collections using the prescribed process at https://kabanero.io/docs/ref/general/collection-building.html

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Stack java-microprofile not working appsody run

Stack java-microprofile not working appsody run

To Reproduce
Steps to reproduce the behavior:

Install appsody version

appsody version
appsody 0.4.2

Add Collection and set as default

appsody repo add kabanero https://github.com/kabanero-io/collections/releases/download/v0.1.0//kabanero-index.yaml

Check list

appsody list

REPO    	ID               	VERSION  	TEMPLATES        	DESCRIPTION
kabanero	java-microprofile	0.2.9    	*default         	Eclipse MicroProfile on Open Liberty & OpenJ9 using Maven
kabanero	java-spring-boot2	0.3.6    	*default, kotlin 	Spring Boot using OpenJ9 and Maven
kabanero	nodejs           	0.2.5    	*simple          	Runtime for Node.js applications
kabanero	nodejs-express   	0.2.5    	*simple, skaffold	Express web framework for Node.js
kabanero	nodejs-loopback  	0.1.3    	*scaffold        	LoopBack 4 API Framework for Node.js

Do the init

mkdir java-microprofile-app
cd java-microprofile-app/
appsody init java-microprofile

appsody run

See error

Expected behavior
appsody run to work

Actual behaviour
Error

Running development environment...
Running command: docker[pull kabanero/java-microprofile:0.2]
Running docker command: docker[run --rm -p 7777:7777 -p 9080:9080 -p 9443:9443 --name java-microprofile-app-dev -v /Users/csantana23/.m2/repository:/mvn/repository -v /Users/csantana23/dev/case/cloudpak/apps/java-microprofile-app/src:/project/user-app/src -v /Users/csantana23/dev/case/cloudpak/apps/java-microprofile-app/pom.xml:/project/user-app/pom.xml -v /Users/csantana23/.appsody/appsody-controller:/appsody/appsody-controller -t --entrypoint /appsody/appsody-controller kabanero/java-microprofile:0.2 --mode=run]
[Container] Running Install: ../validate.sh && mvn -Dmaven.repo.local=/mvn/repository install -DskipTests
[Container] Installing parent dev.appsody:java-microprofile:0.2.11
[Container] [INFO] Scanning for projects...
[Container] [INFO]
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO] Building java-microprofile 0.2.11
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO]
[Container] [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce (enforce-versions) @ java-microprofile ---
[Container] [INFO] Skipping Rule Enforcement.
[Container] [INFO]
[Container] [INFO] --- maven-install-plugin:2.4:install (default-install) @ java-microprofile ---
[Container] [INFO] Installing /project/user-app/../pom.xml to /mvn/repository/dev/appsody/java-microprofile/0.2.11/java-microprofile-0.2.11.pom
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO] BUILD SUCCESS
[Container] [INFO] ------------------------------------------------------------------------
[Container] [INFO] Total time: 3.129 s
[Container] [INFO] Finished at: 2019-09-05T22:03:50Z
[Container] [INFO] Final Memory: 7M/11M
[Container] [INFO] ------------------------------------------------------------------------
[Container] Project is missing required parent:
[Container]   <parent>
[Container]     <groupId>dev.appsody</groupId>
[Container]     <artifactId>java-microprofile</artifactId>
[Container]     <version>0.2.11</version>
[Container]   </parent>
[Container] [Error] FATAL error APPSODY_PREP command received an error.  The controller is exiting: exit status 1
[Error] Error waiting in 'appsody run' exit status 1

Updating and testing collections requires manual docker build

Describe the bug
I am trying to follow instruction in readme on this repo and also in public https://kabanero.io/docs/ref/general/collection-building.html.
If I use export IMAGE_REGISTRY_ORG=kabanero then it always seem to be pulling image from docker hub during appsody init so changes to the collection are not reflected even after running below command:

. ./ci/build.sh . incubator/java-microprofile/

To workaround the problem, I updated IMAGE_REGISTRY_ORG=mykabanero so now the appsody init failed as below

appsody init local/java-microprofile
Running appsody init...
Downloading java-microprofile template project from file:///Users/mtamboli/ICPA/champ/inst/collections/ci/assets/incubator.java-microprofile.v0.2.14.templates.default.tar.gz
Download complete. Extracting files from java-microprofile.tar.gz
Setting up the development environment
Running command: docker[pull mykabanero/java-microprofile:0.2]
[Warning] Docker image pull failed: exit status 1
[Warning] The stack init script failed: Failed to run the docker find command: Could not find the image either in docker hub or locally: mykabanero/java-microprofile:0.2
[Warning] Your local IDE may not build properly, but the Appsody container should still work.
[Warning] To try again, resolve the issue then run `appsody init` with no arguments.

So I had to run this command to create the image locally from java-microprofile/image:
docker build -t mykabanero/java-microprofile:0.2 -f Dockerfile-stack .

After that, appsody init pulls updates made to the stack:

appsody init local/java-microprofile
Running appsody init...
Downloading java-microprofile template project from file:///Users/mtamboli/ICPA/champ/inst/collections/ci/assets/incubator.java-microprofile.v0.2.14.templates.default.tar.gz
Download complete. Extracting files from java-microprofile.tar.gz
Setting up the development environment
Running command: docker[pull mykabanero/java-microprofile:0.2]
[Warning] Docker image pull failed: exit status 1
Using local cache for image mykabanero/java-microprofile:0.2
Running command: docker[run --rm --entrypoint /bin/bash mykabanero/java-microprofile:0.2 -c find /project -type f -name .appsody-init.sh]
Extracting project from development environment
[Warning] The stack image does not contain APPSODY_PROJECT_DIR. Using /project
Running command: docker[create --name my-project-extract -v /Users/mtamboli/.m2/repository:/mvn/repository -v /Users/mtamboli/ICPA/champ/inst/mytest/src:/project/user-app/src -v /Users/mtamboli/ICPA/champ/inst/mytest/pom.xml:/project/user-app/pom.xml mykabanero/java-microprofile:0.2]
Running command: docker[cp my-project-extract:/project /Users/mtamboli/.appsody/extract/mytest]
Running command: docker[rm my-project-extract -f]
Project extracted to /Users/mtamboli/ICPA/champ/inst/mytest/.appsody_init
Running command: ./.appsody-init.sh[]
[InitScript] [INFO] Scanning for projects...

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Need to either update document or the script.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Improvements to build.sh output for building collections

Describe the bug
A clear and concise description of what the bug is.

When building collections using ci/build.sh script especially for Java MicroProfile, there is a lot of output which is generated. It is very difficult to process that information especially when things go wrong.

It would really help (by default) if the build script would just display high levels steps that are happening but the detailed steps for each step are saved in individual log files. If any of steps failed, it is easier to go back and look at the log file.

There could be a verbose option to just spit out all the information as it is doing now.

To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/kabanero-io/collections.git
Make changes to Java MicroProfile collection
./ci/build.sh incubator/java-microprofile
Sample Output Snippet:

 == Running pre_env.d scripts
 == Done pre_env.d scripts
 == Running post_env.d scripts
 == Done post_env.d scripts
~/ICPA/champ/collections/ci/build/prefetch ~/ICPA/champ/collections
~/ICPA/champ/collections
STACKS_LIST=incubator/java-microprofile

LINTING: incubator/java-microprofile
LINT PASSED

TOTAL ERRORS: 0
TOTAL WARNINGS: 0

Processing repo: incubator

- BUILDING stack: incubator/java-microprofile
>  docker build --build-arg GIT_ORG_REPO=mtamboli/collections --build-arg IMAGE_REGISTRY_ORG=appsody --build-arg STACK_ID=java-microprofile --build-arg MAJOR_VERSION=0 --build-arg MINOR_VERSION=2 --build-arg PATCH_VERSION=14 --label org.opencontainers.image.created=2019-11-04T14:17:03-0500 --label org.opencontainers.image.version=0.2.14 --label org.opencontainers.image.revision=25813a5afe4acb7b6d7fd969711fdf78e152539e -t appsody/java-microprofile -t appsody/java-microprofile:0 -t appsody/java-microprofile:0.2 -t appsody/java-microprofile:0.2.14 -f /Users/mtamboli/ICPA/champ/collections/incubator/java-microprofile/image/Dockerfile-stack /Users/mtamboli/ICPA/champ/collections/incubator/java-microprofile/image
Sending build context to Docker daemon  40.45kB
Step 1/53 : FROM registry.access.redhat.com/ubi8/ubi
latest: Pulling from ubi8/ubi
c65691897a4d: Pull complete 
641d7cc5cbc4: Pull complete 
Digest: sha256:f3d42effb75ef738fbb89b26f6c971de4049626eddc367c4332fbc6a3a168d83
Status: Downloaded newer image for registry.access.redhat.com/ubi8/ubi:latest
 ---> 11f9dba4d1bc
Step 2/53 : LABEL vendor="Kabanero"     name="kabanero/java-microprofile"     version="0.2.10"     summary="Image for Kabanero java-microprofile development"     description="This image contains the Kabanero development stack for the java-microprofile collection"
 ---> Running in ed6257222f4f
Removing intermediate container ed6257222f4f
 ---> 28c48a8e265c
Step 3/53 : RUN yum upgrade --disableplugin=subscription-manager -y    && yum clean --disableplugin=subscription-manager packages    && echo 'Finished installing dependencies'
 ---> Running in e8285defeff3
Red Hat Universal Base Image 8 (RPMs) - AppStre 622 kB/s | 2.3 MB     00:03    
Red Hat Universal Base Image 8 (RPMs) - BaseOS  233 kB/s | 755 kB     00:03    
Dependencies resolved.
================================================================================
 Package        Arch           Version               Repository            Size
================================================================================
Upgrading:
 tzdata         noarch         2019c-1.el8           ubi-8-baseos         467 k

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 467 k
Downloading Packages:
tzdata-2019c-1.el8.noarch.rpm                   237 kB/s | 467 kB     00:01    
--------------------------------------------------------------------------------
Total                                           237 kB/s | 467 kB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Upgrading        : tzdata-2019c-1.el8.noarch                              1/2 
  Cleanup          : tzdata-2019b-1.el8.noarch                              2/2 
  Verifying        : tzdata-2019c-1.el8.noarch                              1/2 
  Verifying        : tzdata-2019b-1.el8.noarch                              2/2 
Installed products updated.

Upgraded:
  tzdata-2019c-1.el8.noarch                                                     

Complete!
0 files removed
Finished installing dependencies
Removing intermediate container e8285defeff3
 ---> 160d5d94a3e6
Step 4/53 : USER root
 ---> Running in e2c42ad6859b
Removing intermediate container e2c42ad6859b
 ---> 87d1d03a4d62
Step 5/53 : RUN groupadd --gid 1000 java_group  && useradd --uid 1000 --gid java_group --shell /bin/bash --create-home java_user
 ---> Running in e6b728f09881
Removing intermediate container e6b728f09881
 ---> 55fe00690423
Step 6/53 : RUN yum install --disableplugin=subscription-manager -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm     && yum install --disableplugin=subscription-manager -y curl xmlstarlet wget
 ---> Running in a8ce77939568
Red Hat Universal Base Image 8 (RPMs) - AppStre 2.9 kB/s | 4.2 kB     00:01    
Red Hat Universal Base Image 8 (RPMs) - BaseOS  2.8 kB/s | 3.8 kB     00:01    
epel-release-latest-7.noarch.rpm                 10 kB/s |  15 kB     00:01    
Dependencies resolved.
================================================================================
 Package              Arch           Version         Repository            Size
================================================================================
Installing:
 epel-release         noarch         7-12            @commandline          15 k

Transaction Summary
================================================================================
Install  1 Package

Total size: 15 k
Installed size: 24 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Installing       : epel-release-7-12.noarch                               1/1 
  Running scriptlet: epel-release-7-12.noarch                               1/1 
  Verifying        : epel-release-7-12.noarch                               1/1 
Installed products updated.

Installed:
  epel-release-7-12.noarch                                                      

Complete!
Extra Packages for Enterprise Linux 7 - x86_64  3.3 MB/s |  16 MB     00:04    
Last metadata expiration check: 0:00:03 ago on Mon Nov  4 19:17:47 2019.
Package curl-7.61.1-8.el8.x86_64 is already installed.
Dependencies resolved.
================================================================================
 Package         Arch        Version                 Repository            Size
================================================================================
Installing:
 xmlstarlet      x86_64      1.6.1-1.el7             epel                  62 k
 wget            x86_64      1.19.5-7.el8_0.1        ubi-8-appstream      734 k
Installing dependencies:
 libxslt         x86_64      1.1.32-3.el8            ubi-8-baseos         249 k

Transaction Summary
================================================================================
Install  3 Packages

Total download size: 1.0 M
Installed size: 3.7 M
Downloading Packages:
(1/3): xmlstarlet-1.6.1-1.el7.x86_64.rpm         52 kB/s |  62 kB     00:01    
(2/3): libxslt-1.1.32-3.el8.x86_64.rpm          158 kB/s | 249 kB     00:01    
(3/3): wget-1.19.5-7.el8_0.1.x86_64.rpm         418 kB/s | 734 kB     00:01    
--------------------------------------------------------------------------------
Total                                           347 kB/s | 1.0 MB     00:03     
warning: /var/cache/dnf/epel-a56bdfa2f5efdfb9/packages/xmlstarlet-1.6.1-1.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Extra Packages for Enterprise Linux 7 - x86_64  1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x352C64E5:
 Userid     : "Fedora EPEL (7) <[email protected]>"
 Fingerprint: 91E9 7D7C 4A5E 96F1 7F3E 888F 6A2F AEA2 352C 64E5
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Installing       : libxslt-1.1.32-3.el8.x86_64                            1/3 
  Installing       : xmlstarlet-1.6.1-1.el7.x86_64                          2/3 
  Installing       : wget-1.19.5-7.el8_0.1.x86_64                           3/3 
  Running scriptlet: wget-1.19.5-7.el8_0.1.x86_64                           3/3 
  Verifying        : xmlstarlet-1.6.1-1.el7.x86_64                          1/3 
  Verifying        : wget-1.19.5-7.el8_0.1.x86_64                           2/3 
  Verifying        : libxslt-1.1.32-3.el8.x86_64                            3/3 
Installed products updated.

Installed:
  xmlstarlet-1.6.1-1.el7.x86_64           wget-1.19.5-7.el8_0.1.x86_64          
  libxslt-1.1.32-3.el8.x86_64            

Complete!
Removing intermediate container a8ce77939568
 ---> 1a192a6371f6
Step 7/53 : COPY ./LICENSE /licenses/
 ---> 5148fec1c1ac
Step 8/53 : COPY ./project /project
 ---> 1e3988f9e7a9
Step 9/53 : COPY ./config /config
 ---> dbae5ba40910
Step 10/53 : ENV JAVA_VERSION jdk8u222-b10_openj9-0.15.1
 ---> Running in 495f04b49fe1
Removing intermediate container 495f04b49fe1
 ---> 15de984cbc33
Step 11/53 : RUN set -eux;    ESUM='20cff719c6de43f8bb58c7f59e251da7c1fa2207897c9a4768c8c669716dc819';    BINARY_URL='https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz';    curl -LfsSo /tmp/openjdk.tar.gz ${BINARY_URL};    echo "${ESUM} */tmp/openjdk.tar.gz" | sha256sum -c -;    mkdir -p /opt/java/openjdk;    cd /opt/java/openjdk;    tar -xf /tmp/openjdk.tar.gz --strip-components=1;    rm -rf /tmp/openjdk.tar.gz;
 ---> Running in 01569d628dc1
+ ESUM=20cff719c6de43f8bb58c7f59e251da7c1fa2207897c9a4768c8c669716dc819
+ BINARY_URL=https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz
+ curl -LfsSo /tmp/openjdk.tar.gz https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz
+ echo '20cff719c6de43f8bb58c7f59e251da7c1fa2207897c9a4768c8c669716dc819 */tmp/openjdk.tar.gz'
+ sha256sum -c -
/tmp/openjdk.tar.gz: OK
+ mkdir -p /opt/java/openjdk
+ cd /opt/java/openjdk
+ tar -xf /tmp/openjdk.tar.gz --strip-components=1
+ rm -rf /tmp/openjdk.tar.gz
Removing intermediate container 01569d628dc1
 ---> 67cce315d72b
Step 12/53 : ENV JAVA_HOME=/opt/java/openjdk    PATH="/opt/java/openjdk/bin:$PATH"
 ---> Running in f2b77f6b9ce9
Removing intermediate container f2b77f6b9ce9
 ---> 36afe8ef1d1b
Step 13/53 : ENV JAVA_TOOL_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions -XX:+UseContainerSupport -XX:+IdleTuningCompactOnIdle -XX:+IdleTuningGcOnIdle"
 ---> Running in ee60320273b1
Removing intermediate container ee60320273b1
 ---> 63218f2aeca0
Step 14/53 : ARG MAVEN_VERSION=3.6.2
 ---> Running in fb42b119b76c
Removing intermediate container fb42b119b76c
 ---> 9ea8a82bd177
Step 15/53 : ARG USER_HOME_DIR="/root"
 ---> Running in 86830a3e9cd0
Removing intermediate container 86830a3e9cd0
 ---> 1a40a6bda39f
Step 16/53 : ARG SHA=d941423d115cd021514bfd06c453658b1b3e39e6240969caf4315ab7119a77299713f14b620fb2571a264f8dff2473d8af3cb47b05acf0036fc2553199a5c1ee
 ---> Running in 01655d0cec4e
Removing intermediate container 01655d0cec4e
 ---> 092662c6d860
Step 17/53 : ARG BASE_URL=https://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/
 ---> Running in 4df50dbdb693
Removing intermediate container 4df50dbdb693
 ---> 01bd1a3d4767
Step 18/53 : RUN mkdir -p /usr/share/maven /usr/share/maven/ref     && curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz     && echo "${SHA}  /tmp/apache-maven.tar.gz" | sha512sum -c -     && tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1     && rm -f /tmp/apache-maven.tar.gz     && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn
 ---> Running in e374814781dd
/tmp/apache-maven.tar.gz: OK
Removing intermediate container e374814781dd
 ---> b5afddfb34f5
Step 19/53 : ENV MAVEN_HOME /usr/share/maven
 ---> Running in e80568a74570
Removing intermediate container e80568a74570
 ---> 5a98665f37e0
Step 20/53 : ENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"
 ---> Running in 04201c0686d1
Removing intermediate container 04201c0686d1
 ---> 43204fb348db
Step 21/53 : RUN  /project/util/check_version build
 ---> Running in 20e5e23b7da9
Removing intermediate container 20e5e23b7da9
 ---> 65388a1efd0d
Step 22/53 : WORKDIR /project/
 ---> Running in 0d378bab0dd2
Removing intermediate container 0d378bab0dd2
 ---> 6ab9ca4dc1e4
Step 23/53 : RUN mkdir -p /mvn/repository
 ---> Running in 96b8fe876a91
Removing intermediate container 96b8fe876a91
 ---> 03e2b012522d
Step 24/53 : RUN mvn -B -Dmaven.repo.local=/mvn/repository -N io.takari:maven:wrapper -Dmaven=$(mvn help:evaluate -Dexpression=maven.version -q -DforceStdout)
 ---> Running in 090d3d263285
[INFO] Scanning for projects...
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/net/wasdev/wlp/maven/parent/liberty-maven-app-parent/2.6.4/liberty-maven-app-parent-2.6.4.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/net/wasdev/wlp/maven/parent/liberty-maven-app-parent/2.6.4/liberty-maven-app-parent-2.6.4.pom (5.0 kB at 7.8 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/net/wasdev/wlp/maven/liberty-maven/2.6.4/liberty-maven-2.6.4.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/net/wasdev/wlp/maven/liberty-maven/2.6.4/liberty-maven-2.6.4.pom (2.0 kB at 11 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/net/wasdev/maven/parent/parent/1.4/parent-1.4.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/net/wasdev/maven/parent/parent/1.4/parent-1.4.pom (5.6 kB at 33 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/openliberty/features/features-bom/19.0.0.7/features-bom-19.0.0.7.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/openliberty/features/features-bom/19.0.0.7/features-bom-19.0.0.7.pom (95 kB at 303 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/maven-metadata.xml
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/maven-metadata.xml (724 B at 4.4 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.7.6/maven-0.7.6.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.7.6/maven-0.7.6.pom (2.3 kB at 14 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/27/takari-27.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/27/takari-27.pom (14 kB at 86 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.7.6/maven-0.7.6.jar
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.7.6/maven-0.7.6.jar (9.0 kB at 55 kB/s)
[INFO] 
[INFO] -------------------< dev.appsody:java-microprofile >--------------------
[INFO] Building java-microprofile 0.2.14
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- maven:0.7.6:wrapper (default-cli) @ java-microprofile ---
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.5.5/maven-wrapper-0.5.5.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.5.5/maven-wrapper-0.5.5.pom (2.4 kB at 15 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.pom (1.8 kB at 11 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/15/takari-15.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/15/takari-15.pom (15 kB at 90 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/com/google/guava/guava/14.0.1/guava-14.0.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/com/google/guava/guava/14.0.1/guava-14.0.1.pom (5.4 kB at 33 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/com/google/guava/guava-parent/14.0.1/guava-parent-14.0.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/com/google/guava/guava-parent/14.0.1/guava-parent-14.0.1.pom (2.6 kB at 15 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom (4.8 kB at 29 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.pom (11 kB at 62 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/33/commons-parent-33.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/33/commons-parent-33.pom (53 kB at 305 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/apache/13/apache-13.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/apache/13/apache-13.pom (14 kB at 83 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.15/plexus-utils-3.0.15.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.15/plexus-utils-3.0.15.pom (3.1 kB at 19 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus/3.3.1/plexus-3.3.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus/3.3.1/plexus-3.3.1.pom (20 kB at 143 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/sonatype/spice/spice-parent/17/spice-parent-17.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/sonatype/spice/spice-parent/17/spice-parent-17.pom (6.8 kB at 41 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/sonatype/forge/forge-parent/10/forge-parent-10.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/sonatype/forge/forge-parent/10/forge-parent-10.pom (14 kB at 83 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/javax/inject/javax.inject/1/javax.inject-1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/javax/inject/javax.inject/1/javax.inject-1.pom (612 B at 3.8 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.pom (4.7 kB at 15 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/14/takari-14.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/14/takari-14.pom (13 kB at 81 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.16/plexus-utils-3.0.16.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.16/plexus-utils-3.0.16.pom (3.4 kB at 15 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/mav
....

Expected behavior
A clear and concise description of what you expected to happen.

There could be a verbose option to just spit out all the information as it is doing now.

Actual behaviour
What is the actual behaviour.

Currently, the behavior is to display lots of information (including lots of maven downloads for Java MicroProfile) and you loose the flow of the script and difficult to debug.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

In the collections repo Readme file , collections build steps are present however we don't know how to create a git release and push build artifacts there for kabanero-pipelines testing

Describe the bug

In the collections repo Readme file , collections build steps are present however we don't know how to create a git release and push build artifacts there for kabanero-pipelines testing
2.Steve GROEGER updated in one of the thread below information for setting environment parameters , which is not mentioned clearly in the readme file in case of local build step

The only one that needs to be worried about if you are building locally is: IMAGE_REGISTRY_ORG. As that will determine which org the images get created under.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Stack you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Bug: Location in the kabanero-index.json file is incorrect

Describe the bug
A clear and concise description of what the bug is.
For curated and rebuilt collectio, kabanero-index.json file link in the kabanero instance dashboard has the incorrect location.
For example: Location below is not correct and does not exist.

{
"displayName": "Kabanero Eclipse MicroProfile® template",
"description": "Eclipse MicroProfile on Open Liberty & OpenJ9 using Maven",
"language": "java",
"projectType": "appsodyExtension",
"projectStyle": "Appsody",
"location": "https://github.com/was-svt/kabanero-collections/releases/download/0.2.0/incubator.java-microprofile.v0.2.18.templates.default.tar.gz",
"links": {
"self": "/devfiles/java-microprofile/devfile.yaml"
}
To Reproduce
Steps to reproduce the behavior:

Rebuild collection at a different location for example GHE
Look at the generated kabanero-index.json file for correct location

Expected behavior
A clear and concise description of what you expected to happen.

Index file is used to initialize projects using codewind which does to work.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Jane can import existing application source code into an Appsody project, associating it with an Appsody stack. Appsody Requirement.

Tekton pipeline default `buildbud` step fails

The tekton default buildbud step fails at STEP 6.

xmlstarlet-1.6.1-1.el7.x86_64 unzip-6.0-41.el8.x86_64 libxslt-1.1.32-3.el8.x86_64 Complete!STEP 4: RUN yum install --disableplugin=subscription-manager -y wget ca-certificatesLast metadata expiration check: 0:00:16 ago on Fri Sep 27 03:36:16 2019.Package ca-certificates-2018.2.24-6.el8.noarch is already installed.Dependencies resolved.================================================================================ Package Arch Version Repository Size================================================================================Installing: wget x86_64 1.19.5-7.el8_0.1 ubi-8-appstream 734 kTransaction Summary================================================================================Install 1 PackageTotal download size: 734 kInstalled size: 2.8 MDownloading Packages:wget-1.19.5-7.el8_0.1.x86_64.rpm 671 kB/s | 734 kB 00:01 --------------------------------------------------------------------------------Total 668 kB/s | 734 kB 00:01 Running transaction checkTransaction check succeeded.Running transaction testTransaction test succeeded.Running transaction Preparing : 1/1 Installing : wget-1.19.5-7.el8_0.1.x86_64 1/1 Running scriptlet: wget-1.19.5-7.el8_0.1.x86_64 1/1 Verifying : wget-1.19.5-7.el8_0.1.x86_64 1/1 Installed products updated.Installed: wget-1.19.5-7.el8_0.1.x86_64 Complete!STEP 5: ENV JAVA_VERSION 1.8.0_sr5fp37STEP 6: RUN set -eux; ESUM='51f6600dcc51c238bd4fbed73521e225094d7afa9afa2c8fb35ea78519a71930'; YML_FILE='sdk/linux/x86_64/index.yml'; BASE_URL="https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta/"; wget -q -U UA_IBM_JAVA_Docker -O /tmp/index.yml ${BASE_URL}/${YML_FILE}; JAVA_URL=$(sed -n '/^'${JAVA_VERSION}:'/{n;s/\s*uri:\s//p}'< /tmp/index.yml); wget -q -U UA_IBM_JAVA_Docker -O /tmp/ibm-java.bin ${JAVA_URL}; echo "${ESUM} /tmp/ibm-java.bin" | sha256sum -c -; echo "INSTALLER_UI=silent" > /tmp/response.properties; echo "USER_INSTALL_DIR=/opt/ibm/java" >> /tmp/response.properties; echo "LICENSE_ACCEPTED=TRUE" >> /tmp/response.properties; mkdir -p /opt/ibm; chmod +x /tmp/ibm-java.bin; /tmp/ibm-java.bin -i silent -f /tmp/response.properties; rm -f /tmp/response.properties; rm -f /tmp/index.yml; rm -f /tmp/ibm-java.bin;+ ESUM=51f6600dcc51c238bd4fbed73521e225094d7afa9afa2c8fb35ea78519a71930+ YML_FILE=sdk/linux/x86_64/index.yml+ BASE_URL=https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta/+ wget -q -U UA_IBM_JAVA_Docker -O /tmp/index.yml https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta//sdk/linux/x86_64/index.yml++ sed -n '/^1.8.0_sr5fp37:/{n;s/\s*uri:\s//p}'+ JAVA_URL=+ wget -q -U UA_IBM_JAVA_Docker -O /tmp/ibm-java.binwget: missing URLUsage: wget [OPTION]... [URL]...Try `wget --help' for more options.subprocess exited with status 1subprocess exited with status 1error building at STEP "RUN set -eux; ESUM='51f6600dcc51c238bd4fbed73521e225094d7afa9afa2c8fb35ea78519a71930'; YML_FILE='sdk/linux/x86_64/index.yml'; BASE_URL="https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta/"; wget -q -U UA_IBM_JAVA_Docker -O /tmp/index.yml ${BASE_URL}/${YML_FILE}; JAVA_URL=$(sed -n '/^'${JAVA_VERSION}:'/{n;s/\s*uri:\s//p}'< /tmp/index.yml); wget -q -U UA_IBM_JAVA_Docker -O /tmp/ibm-java.bin ${JAVA_URL}; echo "${ESUM} /tmp/ibm-java.bin" | sha256sum -c -; echo "INSTALLER_UI=silent" > /tmp/response.properties; echo "USER_INSTALL_DIR=/opt/ibm/java" >> /tmp/response.properties; echo "LICENSE_ACCEPTED=TRUE" >> /tmp/response.properties; mkdir -p /opt/ibm; chmod +x /tmp/ibm-java.bin; /tmp/ibm-java.bin -i silent -f /tmp/response.properties; rm -f /tmp/response.properties; rm -f /tmp/index.yml; rm -f /tmp/ibm-java.bin;": exit status 1 Step failed

Build process doesn't test the build of the deployable Dockerfiles

When the build process runs it does a docker build of each of the collections ./image/Dockerfile-stack files, but it doesn't build the docker images that will get created when an app is to be deployed, ie the ./image/project/Dockerfile.

Need a process to be able to test the build / run of the ./image/project/Dockerfile

Regression test Nginx workaround for leveraging GHE to host the collection on OCP

Kabanero on OKD 3.11 supported the usage of an Nginx workaround to host the collection in GHE. We need to validate that this workaround still works with Kabanero and OCP 4.2.

The manifest.mf file in the pipeline tar.gz doesnt contain sha256 signatures

Describe the bug
The manifest.mf file in the pipeline tar.gz doesnt contain sha256 signatures. It contains an entry for the sha256 but the actual sha256 value is not included in the file.

Expected behavior
File should look like:

contents:
- file: build-deploy-pipeline.yaml
  sha256: e21393e3603cc13e29b3520db4af91fcf83a0bb2a76864442b43991e04c1317e
- file: deploy-task.yaml
  sha256: a4e13262cc6bce993f9ce29805720b2019aa31b0d4644c832cd514eb35e6a0c5
- file: build-task.yaml
  sha256: bc5e04b5a03d6e0016a71e025b66c7da2efe80031c675db928b6c995de217d3f

Actual behaviour
Actual file is:

contents:
- file: build-task.yaml
  sha256:
- file: deploy-task.yaml
  sha256:
- file: build-deploy-pipeline.yaml
  sha256:

Environment Details (please complete the following information):

Version [e.g. 22]: v0.1.2

Jane is able to view the documentation for the collection that she is using in an air gap scenario.

java-spring-boot2 Dockerfile fails trying to find JRE 1.8.0_sr5fp37

Describe the bug
I am using the kabanero java-spring-boot2 stack. The appsody build is failing. The Dockerfile downloads a yaml file from https://public.dhe.ibm.com and expects to find a fix pack labeled 1.8.0_sr5fp37 but there is no such fix pack in the response.

To Reproduce

appsody repo add kabanero https://github.com/kabanero-io/collections/releases/download/v0.1.0/kabanero-index.yaml
appsody init kabanero/java-spring-boot2
appsody build

Expected behavior
appsody build is successful

Actual behaviour
[Docker] + BASE_URL=https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta/
[Docker] + wget -q -U UA_IBM_JAVA_Docker -O /tmp/index.yml https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta//sdk/linux/x86_64/index.yml
[Docker] [0m[91m++ sed -n '/^1.8.0_sr5fp37:/{n;s/\s*uri:\s//p}'
[Docker] [0m[91m+ JAVA_URL=
[Docker] + wget -q -U UA_IBM_JAVA_Docker -O /tmp/ibm-java.bin
[Docker] [0m[91mwget: missing URL
[Docker] Usage: wget [OPTION]... [URL]...

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version: 0.4.2
Collection you are using: java-spring-boot2

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
The Dockerfile does a wget to https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/meta/sdk/linux/x86_64/index.yml. When I go there I get this response:

# version: uri
---
1.8.0_sr5fp6:
    uri: https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/8.0.5.6/linux/x86_64/ibm-java-sdk-8.0-5.6-x86_64-archive.bin
    sha256sum: b5e2824313e62d647c7c7c7c8a6eb8704e445e915da460d379aedd30e6835030
    license: http://www14.software.ibm.com/cgi-bin/weblap/lap.pl?la_formnum=&li_formnum=L-PMAA-A3Z8P2&title=IBM%AE+SDK%2C+Java%99+Technology+Edition%2C+Version+8.0&l=en

1.8.0_sr5fp40:
    uri: https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/8.0.5.40/linux/x86_64/ibm-java-sdk-8.0-5.40-x86_64-archive.bin
    sha256sum: bc53faf476655e565f965dab3db37f9258bfc16bb8c5352c93d43d53860b79d3
    license: http://www14.software.ibm.com/cgi-bin/weblap/lap.pl?la_formnum=&li_formnum=L-SMKR-AVSEUH&title=IBM%AE+SDK%2C+Java%99+Technology+Edition%2C+Version+8.0&l=en

1.8.0_sr5fp41:
    uri: https://public.dhe.ibm.com/ibmdl/export/pub/systems/cloud/runtimes/java/8.0.5.41/linux/x86_64/ibm-java-sdk-8.0-5.41-x86_64-archive.bin
    sha256sum: 6545147d99ed83124eb6f0091b262d97089ba41b2c8c7d8adc7836836af29658
    license: http://www14.software.ibm.com/cgi-bin/weblap/lap.pl?la_formnum=&li_formnum=L-SMKR-AVSEUH&title=IBM%AE+SDK%2C+Java%99+Technology+Edition%2C+Version+8.0&l=en

The Dockerfile uses sed to look for a string 1.8.0_sr5fp37 in the yaml file. Since that's not there, JAVA_URL isn't set to anything and the following wget fails.

Add sample trigger to collection

Add a new sample trigger to a collection

Instructions on cloning and extending collections based on `appsody stack`

Is your feature request related to a problem? Please describe.
The current instructions for working with collections are based on ./ci/build.sh.
Starting with appsody 0.4.6, and later augmented in 0.4.7, build.sh is deprecated in favor of appsody stack commands.

Describe the solution you'd like
The instructions in the collections README.md file should be reworked to leverage the new appsody stack commands, since they reduce the number of prereqs required for build.sh (e.g. python and pip) and make it much easier for Champ to work in Windows environments.

Describe alternatives you've considered
The alternative is for Kabanero to keep on using the shell-based procedures, but not only the current support is worse than what is in appsody stack, it will become costlier and more error prone over time as the appsody team stops making improvements to build.sh or deprecate it altogether.

Additional context
This work can be easier to accomplish by waiting on the delivery of:
appsody/appsody#526

Collections not honoring the liberty version in Java Microprofile Stack

Describe the bug

Collections not honoring the liberty version in Java Microprofile stack.

I curated collections and updated the version of Liberty to 190010.
Created a release of the collections https://github.com/mtamboli/collections/releases/tag/v0.3.1
Updated Kabanero CR instate to use this collections
Created a project and webhook in Tekton dashboard for the Java MicroProfile project
Application was deployed but the Liberty version of the application is 19009

Same behavior is true for default collections too.
When I look at the pom.xml for the Java MicroProfile stack for latest collections, it has Liberty version 19008. But deployed application with pipeline using default collections, I am seeing Liberty version 19009.
https://github.com/kabanero-io/collections/blob/master/incubator/java-microprofile/image/project/pom.xml

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Activated collection metadata contains unresolved variable

Describe the bug
When a collection is activated on the Kabanero cluster, the collection metadata for "image" contains an unresolved variable "IMAGE_REGISTRY_ORG"

To Reproduce
Activate collection with the latest version of collections:

https://github.com/kabanero-io/collections/releases/download/v0.2.0-beta2/kabanero-index.yaml

Additional context
Caused by change: 7625518

The values for image, as in:

images:

id: java-spring-boot2
image: kabanero/java-spring-boot2:0.3

is stored by the Kabanero operator and used to validate which collections are active and can be built by pipelines. This value needs to be resolved.

Champ can edit and customize an existing collection in his private Hub, and configure the settings and access for Jane using the CLI..

Instructions on how to update Kabanero to use custom collections

Describe the bug
Instructions show how to locally update and test collections. But there is no documentation on how to use these updates collections with Tekton webhook and pipelines. Need this documentation for testing.

https://kabanero.io/docs/ref/general/collection-building.html

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Tekton Pipeline to build collection hub for development scenarios.

Is your feature request related to a problem? Please describe.
Want to demonstrate a development pipeline for the collection hub.

Describe the solution you'd like
The build collection hub pipeline should be a precursor to a GitHub webhook which could help automate the process of building collections. The experience for Champ should be similar to Jane's in that we have discrete pipelines for Building and Testing and publishing and activating. This epic is to move the rock forward, by working on this pipeline we can start to uncover concrete design issues we need to solve in doing collection hub development.

Of primary demonstration, we'd like to show in a few milestones, the ability for Champ to update a collection with new maintenance, primarily security-related, and that with the right testing automation the new maintenance can be rolled out automatically.

Deliver the collection for Spring & Liberty

codewind app metrics/performance dashboard is not enabled by default for Java MicroProfile stack

Describe the bug
Java MicroProfile stack does not support application metrics or the performance dashboard by default in VSCode+Codewind 0.4.0. If users try to launch the monitor or performance dashboard for java MP project, it will throw the following error in the log:

[Container]  INFO   WARNING   SRVE0190E: File not found: /javametrics-dash/

and a pop-up message in the bottom right corner of VSCode

JMP-proj does not support application metrics or the performance dashboard.

I see that the application metrics and performance dashboard are enabled by default for nodejs express project

To Reproduce
Steps to reproduce the behavior:

In VSCode+Codewin0.4.0, create a new Java MicroProfile project using Appsody Stacks - kabanero template
After it done creating the project, building and running the app, launch application monitor by right click on the app > Open Application Monitor
you will see the error message

Expected behavior
Should be able to view app metrics and performance dashboard for java microProfile project in codewind by default without extra configurations

Actual behaviour
can't view app monitor and performance dashboard in codewind

Environment Details (please complete the following information):

OS: Mac
VS Code + Codewind 0.4.0
Appsody stacks - Kabanero 0.1.2 or 0.2.0

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Java-microprofile collections from latest v0.1.2 collection release is throwing error in the pipelinerun due to pom file

Describe the bug
A clear and concise description of what the bug is.
We got latest appsody collections from our Kabanero v0.1.2 for java-microprofile and tried running the pipelinerun on that collection. The pielinerun is failing as per below error showing that pom file has some dependency which appsody stack cannot download.

Pipelinerun error in Build task pod.

TEP 19: WORKDIR /project/user-app
STEP 20: RUN mvn install -DskipTests
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/dev/appsody/java-microprofile/0.2.11/java-microprofile-0.2.11.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for dev.appsody.starter.java-microprofile:starter-app:1.0-SNAPSHOT: Could not find artifact dev.appsody:java-microprofile:pom:0.2.11 in central (https://repo.maven.apache.org/maven2) and 'parent.relativePath' points at wrong local POM @ line 8, column 13
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project dev.appsody.starter.java-microprofile:starter-app:1.0-SNAPSHOT (/project/user-app/pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for dev.appsody.starter.java-microprofile:starter-app:1.0-SNAPSHOT: Could not find artifact dev.appsody:java-microprofile:pom:0.2.11 in central (https://repo.maven.apache.org/maven2) and 'parent.relativePath' points at wrong local POM @ line 8, column 13 -> [Help 2]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
subprocess exited with status 1
subprocess exited with status 1
error building at STEP "RUN mvn install -DskipTests": exit status 1
[root@escapes1 manual-pipeline-runs]# ls -ltr

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Actual behaviour
What is the actual behaviour.

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Jane can import existing application source code into a Kabanero project, associating it with a Kabanero Collection.

Liberty version in Java-MicroProfile stack is hard coded

Describe the bug
A clear and concise description of what the bug is.

I see that Java Microprofile stack in the Java- Microprofile collection has the Liberty version in 3 places (pom.xml of the stack) which determines what version of Liberty will be used by Jane as well as by the kabaner pipelines. There does not seem like an easy way to change it except re-building the collections.

Champ should have an easy way to move to the latest Liberty build without need to rebuild the collection which is a lot of work.

Do not understand how kabanero updates the Liberty version? Is it dependent on appsody stack updating it?

Is there an easy way for Jane to try a different version of Liberty in case she is hitting issues and would like to try a more recent version before she can let Champ know about it.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

As Champ, I would like easy way to update the liberty versions used in Java-MP stack without need to rebuild collection.

Additionally, it would be nice for Jane to override liberty version in her local environment only for debugging purposes.

Actual behaviour
What is the actual behaviour.

you need to update the Liberty version in 3 places and then rebuild collection and stack.
https://github.com/kabanero-io/collections/blob/master/incubator/java-microprofile/image/project/pom.xml

Environment Details (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Shell window hangs after [Process Completed] message for build.sh

Describe the bug
Shell window hangs after [Process Completed] message for build.sh

To Reproduce
Steps to reproduce the behavior:

Go to cmd window in collections repo root
run . ./ci/build.sh
Wait for it to run to completion: [Process Completed]
Cannot get back to command prompt

Expected behavior
Anle to get back to command prompt

Actual behaviour
Cannot get back to command prompt

Environment Details (please complete the following information):

OS: iOS
Command window

If applicable please specify:

CLI version:
Collection you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Updates to a collection, causes work to be placed on Jane's work queue, and we will automate what we can of it

Jane makes a change to git and it's pushed through the pipeline.

Demonstrate collections deployed Serverless, as functions scaled to zero w/ Knative

Local test build doesn't easily allow for changing the IMAGE_REGISTRY_ORG on all artefacts

When testing the build of Kabanero artefacts, there is no easy process to update the artefacts (ie the templates) to utilise an updated IMAGE_REGISTRY_ORG environment variable.

Currently the name of the IMAGE_REGISTRY_ORG is hardcoded within the images/image element in the collection.yaml file. If there is a need to test using a different value for the IMAGE_REGISTRY_ORG, then the collections.yaml file in each of the collections needs to be modified.

We need a method for being able to pickup the value of the IMAGE_REGISTRY_ORG environment variable when we update the templates for each collection with the image name defined in the collection.yaml.

Champ can find and install new featured collections available publicly.

Collection Docker file for java-microprofile UBI shouldn't require 100MB download for github.

I'm having timeouts trying to a simple Appsody Build of a new unchanged Appsody project (Appsody Init java-microprofile) pointing at the 0.2.0-beta2 collection.

[Docker] + BINARY_URL=https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz
[Docker] + curl -LfsSo /tmp/openjdk.tar.gz https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz
[Docker] curl: (18) transfer closed with 43474620 bytes remaining to read
[Docker] The command '/bin/sh -c set -eux;    ESUM='20cff719c6de43f8bb58c7f59e251da7c1fa2207897c9a4768c8c669716dc819';    BINARY_URL='https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10_openj9-0.15.1/OpenJDK8U-jdk_x64_linux_openj9_8u222b10_openj9-0.15.1.tar.gz';    curl -LfsSo /tmp/openjdk.tar.gz ${BINARY_URL};    echo "${ESUM} */tmp/openjdk.tar.gz" | sha256sum -c -;    mkdir -p /opt/java/openjdk;    cd /opt/java/openjdk;    tar -xf /tmp/openjdk.tar.gz --strip-components=1;    rm -rf /tmp/openjdk.tar.gz;' returned a non-zero code: 18
[Error] exit status 18

I think the only way to really address it is to FROM a new container that is UBI+JDK.

java-spring-boot2, nodejs , nodejs-express and nodejs-loopback do not.

To Reproduce
run : oc delete collection java-spring-boot2
The collection will delete, then run oc get collection java-spring-boot2 and it will not be re-activated later on.

kabanero-io / collections Goto Github PK

collections's People

Contributors

Stargazers

Watchers

Forkers

collections's Issues

Kabanero Collection Versioning

Definition of terms - current

Background and issues

Issue 1

Issue 2

Issue 3

Versioning changes

Definition of terms - proposed

Add collection version

Maintain provenance of collections via labeling

Version all artifacts with release version

Version customized collections with Customized collections version

Use explicit patch levels in all collection configuration, allow optional override

User scenarios

Release version X.Y.Z of Kabanero collections

Champ wants to customize Kabanero collections release X.Y.Z (assuming Champ has travis available)

Champ wants to automatically update all applications built on A.B.C with a security fix (assuming travis is available and optional major.minor override is configured on A.B.C)

Champ wants to optionally update all applications built on A.B.C with a security fix (assuming travis is available)

Recommend Projects

Recommend Topics

Recommend Org