Devfile command execution #2735

maysunfaisal · 2020-03-19T22:21:31Z

Signed-off-by: Maysun J Faisal maysun.j.faisal@ibm.com

What type of PR is this?
/kind feature

What does does this PR do / why we need it:
This PR:

executes devBuild and devRun commands from the devfile
bootstraps supervisord to the devfile run component container from an init container
makes supervisord the entrypoint of the devfile run component container if no entrypoint is mentioned in the devfile
executes the devRun command with supervisord
introduces two new push flags build-command & run-command which can be used instead of devBuild and devRun
unit tests

Which issue(s) this PR fixes:

How to test changes / Special notes to the reviewer:

Until redhat-developer/odo-init-image#52 is merged, pls set ODO_BOOTSTRAPPER_IMAGE=jeevandroid/odo-init-image for testing with the redhat-developer/odo-init-image#52 changes.

odo push
odo push --show-log
odo push --build-command="some build command" --run-command="some run command"

rajivnathan

Initial feedback

rajivnathan · 2020-03-20T01:50:00Z

pkg/devfile/adapters/common/utils.go

 	"github.com/golang/glog"

 	"github.com/openshift/odo/pkg/devfile/versions"
 	"github.com/openshift/odo/pkg/devfile/versions/common"
 )

+const (
+	DefaultDevfileBuildCommand = "devBuild"


We should probably make these lowercase so that we can easily convert the name from the devfile to lowercase and compare directly. Also we can group these together as a type.

eg.

type PredefinedDevfileCommands string const ( DefaultDevfileBuildCommand PredefinedDevfileCommands = "devbuild" DefaultDevfileRunCommand PredefinedDevfileCommands = "devrun" DefaultDevfileDebugCommand PredefinedDevfileCommands = "devdebug" DefaultDevfileTestCommand PredefinedDevfileCommands = "devtest" )

rajivnathan · 2020-03-20T01:50:30Z

pkg/devfile/adapters/common/interface.go

@@ -2,7 +2,7 @@ package common

 // ComponentAdapter defines the functions that platform-specific adapters must implement
 type ComponentAdapter interface {
-	Push(path string, ignoredFiles []string, forceBuild bool, globExps []string) error
+	Push(path string, ignoredFiles []string, forceBuild bool, show bool, globExps []string, devfileBuildCmd, devfileRunCmd string) error


Should we create a struct to group all these together?

Yeah, they should be in a struct. And FWIW, my odo watch PR groups these into a struct as well 😉

Should we create a struct to group all these together?

That would be great. 👍

rajivnathan · 2020-03-20T02:08:13Z

pkg/devfile/adapters/kubernetes/utils/utils.go

+	for i, container := range containers {
+		for _, runCommandComponent := range runCommandComponents {
+			// Check if the container belongs to a run command component
+			if reflect.DeepEqual(container.Name, runCommandComponent) {


Do we need to use reflect.DeepEqual here? Seems like we can just use the == comparator?

rajivnathan · 2020-03-20T02:09:52Z

pkg/devfile/adapters/kubernetes/utils/utils.go

+				// Always mount the supervisord volume in the run component container
+				container.VolumeMounts = append(container.VolumeMounts, corev1.VolumeMount{
+					Name:      kclient.GetSupervisordVolumeName(),
+					MountPath: "/opt/odo/",


We should use a constant for the MountPath value

rajivnathan · 2020-03-20T02:11:29Z

pkg/kclient/kclient.go

@@ -19,6 +19,14 @@ const (
 Please ensure you have an active kubernetes context to your cluster. 
 Consult your Kubernetes distribution's documentation for more details
 `
+	// The init container name for supervisord
+	supervisordInitContainerName = "copy-supervisord"


Should we move these to the supervisord.go file?

rajivnathan · 2020-03-20T02:20:53Z

pkg/devfile/adapters/common/utils.go

@@ -20,3 +31,160 @@ func GetSupportedComponents(data versions.DevfileData) []common.DevfileComponent
 	}
 	return components
 }
+
+// GetCommand iterates through the devfile commands and returns the associated devfile command
+func GetCommand(data versions.DevfileData, commandName string) (command common.DevfileCommand) {


Should this function be in the devfile parser instead?

devfile parser has GetCommands() which returns all the commands from the devfile and is defined in the interface like the other devfile helper functions.

utils.GetCommand() takes a command name as input and returns one command from the devfile parser's GetCommands() output

rajivnathan · 2020-03-20T02:22:22Z

pkg/devfile/adapters/kubernetes/component/adapter.go

@@ -35,17 +37,30 @@ func New(adapterContext common.AdapterContext, client kclient.Client) Adapter {
 type Adapter struct {
 	Client kclient.Client
 	common.AdapterContext
+	pod             *corev1.Pod


Do we need pod in the struct? Should it or a just the necessary values from the pod just be passed along as needed?

We shouldn't store the pod in the struct. And we also would need to update it every time the pod got recreated

johnmcollier · 2020-03-23T15:56:03Z

pkg/devfile/adapters/kubernetes/component/adapter.go

@@ -35,17 +37,30 @@ func New(adapterContext common.AdapterContext, client kclient.Client) Adapter {
 type Adapter struct {
 	Client kclient.Client
 	common.AdapterContext
+	pod             *corev1.Pod


We shouldn't store the pod in the struct. And we also would need to update it every time the pod got recreated

johnmcollier · 2020-03-23T16:01:58Z

pkg/devfile/adapters/common/utils.go

+
+	// If neither is validated, iterate the devfile commands to see for a list of supported commands
+	for _, supportedCommand := range devfileSupportedCommands {
+		if reflect.DeepEqual(supportedCommand.Name, DefaultDevfileBuildCommand) && !validateBuildCommand {


We can safely compare strings directly in Go, so we shouldn't need the refelct.DeepEqual for comparing the string names

johnmcollier · 2020-03-23T16:05:05Z

pkg/devfile/adapters/interface.go

@@ -1,5 +1,5 @@
 package adapters

 type PlatformAdapter interface {
-	Push(path string, ignoredFiles []string, forceBuild bool, globExps []string) error
+	Push(path string, ignoredFiles []string, forceBuild bool, show bool, globExps []string, devfileBuildCmd, devfileRunCmd string) error


As Rajiv mentioned higher up, this function and the other push function should be modified to accept a struct.

See my odo watch PR for how I did it: https://github.com/openshift/odo/blob/a727c2d31fe402a73f9beab046d72366a11123f7/pkg/devfile/adapters/common/types.go#L27

thx, adopted PushParameters from the Watch PR, will rebase on other changes when it is merged

johnmcollier · 2020-03-23T16:06:08Z

pkg/devfile/adapters/common/utils.go

+		fallthrough
+	case DefaultDevfileRunCommand:
+		fallthrough
+	case DefaultDevfileDebugCommand:


I see we're adding in cases for DefaultDevfileDebugCommand and DefaultDevfileTestCommand. Should the Push function be updated to take those in too? Right now it only accepts `[]string, devfileBuildCmd, devfileRunCmd string

We will be having a new command for test and debug like odo execute. They will not be executed through odo push. I am removing the debug and test command name constants to avoid confusion. They can be re-added later on

johnmcollier · 2020-03-23T16:17:27Z

pkg/devfile/adapters/kubernetes/component/adapter.go

+	// Validate the devfile build and run commands
+	pushDevfileCommands, err := common.ValidateAndGetPushDevfileCommands(a.Devfile.Data, a.devfileBuildCmd, a.devfileRunCmd)
+	if err != nil {
+		return err


Can you wrap this error with a message? Maybe something like "Push failed due to validate error"?

johnmcollier · 2020-03-23T16:22:15Z

pkg/devfile/adapters/kubernetes/component/adapter.go

+	if err != nil {
+		return errors.Wrapf(err, "error while waiting for pod  %s", podSelector)
+	}
+	a.pod = pod


Since WaitAndGetPod doesn't wait for a new pod to rollout and for the old one to go away, there could be a race-condition here where the old pod is returned (before it was moved to the terminating state) instead of the new one.

This may be more of a matter of waiting for #2731 to get merged and to use the "Wait for Rollout" function instead.

#2731 adds the wait for rollout to this exact function so we shouldn't need to add any additional waits on this function.

johnmcollier · 2020-03-23T16:25:46Z

pkg/devfile/adapters/kubernetes/component/adapter.go

@@ -292,6 +321,187 @@ func (a Adapter) pushLocal(path string, files []string, delFiles []string, isFor
 	return nil
 }

+// Push syncs source code from the user's disk to the component
+func (a Adapter) execDevfile(pushDevfileCommands []versionsCommon.DevfileCommand, componentExists, show bool) error {


I'm wondering...

We'll need the exec code to be pretty consistent between local (Docker) and Kube. I'm wondering if we should move this out to a new package, like we did for sync (let's call it exec). Then define an interface (let's call it ExecClient) that has one function: ExecCmdInContainer, and both the kclient and lclient would implement it.

It's up to you, but moving this out to its own package now, makes our lives easier for Docker support.

Sounds good, let me do it like the way you did for sync, to be consistent

kadel · 2020-03-24T17:07:49Z

pkg/devfile/adapters/kubernetes/component/adapter.go

+
+			for _, action := range command.Actions {
+				// Change to the workdir and execute the command
+				cmdArr := []string{"/bin/sh", "-c", "cd " + *action.Workdir + " && " + *action.Command}


workdir is an optional field in devfile
If it is not specified the command should be executed in default image directory (no cding just executing the command)

also action.Command is a pointer, so it can be nil, so you should check it before using it, otherwise, it can end with panic

thx, i have already done that in my new commit which i didnt push

i shall make the changes for workdir 👍

maysunfaisal · 2020-03-25T23:37:23Z

@rajivnathan @johnmcollier @kadel PTAL at your convenience. I have addressed the review comments and will be working on the tests for the PR. Thx!

kadel · 2020-03-27T12:43:29Z

pkg/kclient/supervisord.go

+	supervisordInitContainerName = "copy-supervisord"
+
+	// The default image for odo init bootstrapper container
+	defaultBootstrapperImage = "jeevandroid/odo-init-image"


Most of the constants here are already defined in occlient.go (https://github.com/openshift/odo/blob/a8a5eca39b80abf693bbe1e5e98880f9f31bf34a/pkg/occlient/occlient.go#L109)

We should probably abstract it away to one common place and use the same const everywhere. Or just export it occlient and use it here for now, but having it defined in two places will get messy and prone to bugs :-/

Or even better you could modify occlient to use const from here, as there is a bigger chance that this will become long term place to store this.

kadel · 2020-03-27T12:43:47Z

pkg/kclient/supervisord.go

+	supervisordInitContainerName = "copy-supervisord"
+
+	// The default image for odo init bootstrapper container
+	defaultBootstrapperImage = "jeevandroid/odo-init-image"


Most of the constants here are already defined in occlient.go (https://github.com/openshift/odo/blob/a8a5eca39b80abf693bbe1e5e98880f9f31bf34a/pkg/occlient/occlient.go#L109)

We should probably abstract it away to one common place and use the same const everywhere. Or just export it occlient and use it here for now, but having it defined in two places will get messy and prone to bugs :-/

kadel · 2020-03-27T12:46:43Z

pkg/kclient/supervisord.go

+	podTemplateSpec.Spec.InitContainers = append(podTemplateSpec.Spec.InitContainers,
+		corev1.Container{
+			Name:  supervisordInitContainerName,
+			Image: defaultBootstrapperImage,


The image can be overwritten with ODO_BOOTSTRAPPER_IMAGE env variable. This is used in tests and on clusters with restricted network access (image is mirrored to an internal registry)

You should use something like this

https://github.com/openshift/odo/blob/a8a5eca39b80abf693bbe1e5e98880f9f31bf34a/pkg/occlient/occlient.go#L224

thx for reminding me about this, i saw this when going through the odo non experimental path but forgot as i was doing this branch..

johnmcollier · 2020-03-27T14:32:20Z

pkg/kclient/supervisord.go

@@ -0,0 +1,71 @@
+package kclient


A lot of the things in this file aren't specific to Kube (other than AddBootstrapSupervisordInitContainer), could we move this into somewhere common so that it could be used for Docker and Kube odo?

true, i will see where i can move them

kadel · 2020-03-27T14:37:32Z

This is great start @maysunfaisal

I did a couple of tests and it works as I would expect!
It would be just nice to have source code a little bit more integrated with the rest of the code base.

maysunfaisal · 2020-03-27T14:43:01Z

This is great start @maysunfaisal

I did a couple of tests and it works as I would expect!
It would be just nice to have source code a little bit more integrated with the rest of the code base.

@kadel thx, other than the constants, anything you have in mind?

EDIT:

I have also moved out the exec code into its own package exec, since i think a lot of code will be using it. What do you think about the occlient using it? The new exec is a tad bit different but copied from the exec code of assemble-and-restart; we use the reader pipe to output to stdout when --show or log debug is provided.

rajivnathan

I've been using this with che devfiles and things are working really well! Have some further questions/comments.

rajivnathan · 2020-03-27T18:34:23Z

pkg/devfile/adapters/common/utils.go

@@ -20,3 +30,158 @@ func GetSupportedComponents(data versions.DevfileData) []common.DevfileComponent
 	}
 	return components
 }
+
+// GetCommand iterates through the devfile commands and returns the associated devfile command
+func GetCommand(data versions.DevfileData, commandName string) (supportedCommand common.DevfileCommand) {


Most of these functions are specific to commands. To prevent utils.go becoming very large should we maybe move these to a separate file called commands.go?

We can separate things out afterwards since moving it now will complicated handling merge conflicts

rajivnathan · 2020-03-27T18:43:52Z

pkg/devfile/adapters/common/utils.go

+			return supportedCommand
+		}
+	}
+


Can you please add an info level log here so that it's clear the command was not found?

I added commit 14d81a5 to address this

rajivnathan · 2020-03-27T18:48:26Z

pkg/devfile/adapters/common/utils.go

+			supportedCommandActions := getSupportedCommandActions(command)
+
+			// if there is a supported command action of type exec, save it
+			if len(supportedCommandActions) > 0 {


Shouldn't it be an error if a command is found but there are no supportedCommandActions? I'm thinking it is because there's effectively nothing for odo to execute and the user may be left wondering why nothing is happening.

I added commit 14d81a5 to address this

rajivnathan · 2020-03-27T18:59:21Z

pkg/devfile/adapters/common/utils.go

+func ValidateAndGetPushDevfileCommands(data versions.DevfileData, devfileBuildCmd, devfileRunCmd string) ([]common.DevfileCommand, error) {
+	var pushDevfileCommands []common.DevfileCommand
+	// var emptyCommand common.DevfileCommand
+	validateBuildCommand, validateRunCommand := false, false


I initially thought these variables were being used to decide whether to validate or not but it's actually the validation result. Can you please rename validateBuildCommand to isBuildCommandValid
and
validateRunCommand to isRunCommandValid to make it a bit more clear?

I added commit 5378ed9 to address this

rajivnathan · 2020-03-27T19:07:01Z

pkg/devfile/adapters/common/utils.go

+}
+
+// IsCommandPresent checks if the given command is empty or not
+func IsCommandPresent(command common.DevfileCommand) bool {


We can get rid of this function if GetCommand() returns an error when there are no supportedCommandActions

I added commit 14d81a5 to address this

rajivnathan · 2020-03-27T19:39:48Z

pkg/devfile/adapters/common/utils.go

+	validateBuildCommand, validateRunCommand := false, false
+
+	buildCommand := GetBuildCommand(data, devfileBuildCmd)
+	if devfileBuildCmd == "" && !IsCommandPresent(buildCommand) {


If we do the changes mentioned for GetCommand() then this logic can be simplified to just check whether GetBuildCommand() returns an error and then IsCommandValid(). Same for the run command.

I added commit 14d81a5 to address this

rajivnathan · 2020-03-27T19:54:38Z

pkg/devfile/adapters/common/utils.go

+// validateAction validates the given action
+// 1. action has to be of type exec 2. component should be present
+// 3. command should be present
+func validateAction(action common.DevfileCommandAction) bool {


Rather than returning a boolean, I'd suggest to return an error with a clear message for each validation problem. That way when surfacing the error to the user they know what exactly is wrong with their devfile. Instead of checking for true/false we can check err !=nil.

I added commit 14d81a5 to address this

rajivnathan · 2020-03-27T20:18:43Z

pkg/devfile/adapters/common/utils.go

+	}
+
+	if !validateBuildCommand || !validateRunCommand {
+		return []common.DevfileCommand{}, fmt.Errorf("devfile command validation failed, validateBuildCommand: %v validateRunCommand: %v", validateBuildCommand, validateRunCommand)


This is how the error currently looks for the user:

✗ Failed to start component with name openlibertydevfile. Error: Failed to create the component: failed to validate devfile build and run commands: devfile command validation failed, validateBuildCommand: true validateRunCommand: false

With the changes to validateAction() we can just print each of the error messages.

I added commit 5378ed9 to address this

rajivnathan · 2020-03-27T20:34:06Z

pkg/odo/cli/component/push.go

 	namespace string
 }

+// DevfileCommand encapsulates the build and run command
+// which can be explicitly provided during odo push
+type DevfileCommand struct {


Is this needed? Don't believe it's used anywhere.

nope, i forgot to remove it

Removed in commit 14d81a5

adisky

Tried it out, works well!! some nits

adisky · 2020-04-01T10:11:23Z

pkg/devfile/adapters/common/utils.go


 	"github.com/openshift/odo/pkg/devfile/versions"
 	"github.com/openshift/odo/pkg/devfile/versions/common"
 )

+type PredefinedDevfileCommands string


nit: this also can be defined in pkg/devfile/adapters/common/types.go and DevfileBuildCmd in PushParameters could be of type PredefinedDevfileCommands

I thought about this after your suggestion.

So the PushParameters here are the options from the odo push command where as PredefinedDevfileCommands is a type for command names which are pre-defined and supported by odo experimental for devfile. These predefined commands are going to be devbuild, devrun, devdebug & devtest... For now only devbuild and devrun have been defined and implemented. I expect others to be defined and implemented in the upcoming sprints.

So,

commands names devbuild, devrun are of type PredefinedDevfileCommands from the devfile
odo push will use PredefinedDevfileCommands command devbuild for build and PredefinedDevfileCommands command devrun for run

command names randomcommand123, randomcommand456 are of type string for PushParameters from odo push
odo push --build-command="randomcommand123" will use command randomcommand123 for build and PredefinedDevfileCommands command devrun for run
odo push --build-command="randomcommand123" --run-command="randomcommand456" will use command randomcommand123 for build and command randomcommand456 for run

adisky · 2020-04-01T10:26:12Z

pkg/devfile/adapters/common/utils.go

+
+	// type must be exec
+	if *action.Type != common.DevfileCommandTypeExec {
+		return fmt.Errorf("Actions must be of type \"exec\"")


could we print here action name and other places below as there could be multiple actions in devfile

Actions dont have a name in a devfile

commands: - name: devRun actions: - type: exec component: runtime command: "/artifacts/bin/start-server.sh" workdir: /

But we are printing what action number is an error when we call this function to validate

for i, action := range command.Actions { // Check if the command action is of type exec err := validateAction(data, action) if err == nil { glog.V(3).Infof("Action %d maps to component %v", i+1, *action.Component) supportedCommandActions = append(supportedCommandActions, action) } else { problemMsg += fmt.Sprintf("\nProblem with command \"%v\" action #%d: %v", command.Name, i+1, err) } }

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Signed-off-by: Rajiv Senthilnathan <rajivsen@ca.ibm.com>

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

johnmcollier

Overall changes look good and work great for me, so approving this from my end

/lgtm Great work Maysun, really happy to see this get in.

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

kadel · 2020-04-03T17:06:25Z

/test ci/prow/unit

kadel · 2020-04-03T17:52:03Z

/lgtm
^ was already lgtmed by @johnmcollier

/approve

openshift-ci-robot · 2020-04-03T17:52:28Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kadel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [kadel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-bot · 2020-04-03T18:34:57Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-04-03T18:48:11Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-04-03T21:10:10Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-bot · 2020-04-03T23:33:11Z

/retest

Please review the full test history for this PR and help us cut down flakes.

openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. Required by Prow. kind/feature Categorizes issue as a feature request. For PRs, that means that the PR is the implementation labels Mar 19, 2020

openshift-ci-robot requested review from cdrage and elsony March 19, 2020 22:21

rajivnathan reviewed Mar 20, 2020

View reviewed changes

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. Required by Prow. label Mar 21, 2020

maysunfaisal mentioned this pull request Mar 23, 2020

springBoot devfile is not working on OpenShift elsony/odo-devfile-registry#7

Closed

johnmcollier suggested changes Mar 23, 2020

View reviewed changes

openshift-ci-robot assigned johnmcollier Mar 23, 2020

kadel requested changes Mar 24, 2020

View reviewed changes

openshift-ci-robot assigned kadel Mar 24, 2020

maysunfaisal force-pushed the 2654-1 branch from 2f71a23 to 032caa7 Compare March 25, 2020 23:32

openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. Required by Prow. label Mar 25, 2020

maysunfaisal marked this pull request as ready for review March 25, 2020 23:34

kadel reviewed Mar 27, 2020

View reviewed changes

johnmcollier suggested changes Mar 27, 2020

View reviewed changes

rajivnathan suggested changes Mar 27, 2020

View reviewed changes

openshift-ci-robot assigned rajivnathan Mar 27, 2020

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. Required by Prow. label Mar 27, 2020

maysunfaisal changed the title ~~{WIP} Devfile command execution~~ Devfile command execution Mar 31, 2020

openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. Required by Prow. label Mar 31, 2020

kadel mentioned this pull request Apr 1, 2020

Odo url Ingress support #2762

Merged

adisky reviewed Apr 1, 2020

View reviewed changes

maysunfaisal force-pushed the 2654-1 branch from 5378ed9 to dbb4247 Compare April 1, 2020 15:00

openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. Required by Prow. label Apr 1, 2020

maysunfaisal and others added 13 commits April 2, 2020 08:33

Second pass of devfile exec

d3f20c7

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Devfile exec - PR Feedback 1

372c9c3

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Devfile exec unit tests 1

a11b18c

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

First pass of devfile exec

cda7574

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Second pass of devfile exec

0825fa4

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Devfile exec - PR Feedback 1

bf43fe8

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Devfile exec unit tests 1

d673668

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Address review comments from pull/2735#pullrequestreview-383109487

6d3269e

Fix up command validation error messages

bbe856b

Signed-off-by: Rajiv Senthilnathan <rajivsen@ca.ibm.com>

Devfile exec - PR Feedback 2, Unit Tests, etc.

f6b524b

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Rebase cleanup for devfile exec

417e3ff

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Fix error format and validate command bug

e9ac0c2

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

Update devfile integration tests for mandatory devrun

cdf6d49

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

maysunfaisal force-pushed the 2654-1 branch from 1067b69 to cdf6d49 Compare April 2, 2020 13:14

johnmcollier approved these changes Apr 2, 2020

View reviewed changes

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. Required by Prow. label Apr 2, 2020

Temporarily switch odo init image until prod image is updated

8a346c6

Signed-off-by: Maysun J Faisal <maysun.j.faisal@ibm.com>

openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. Required by Prow. label Apr 3, 2020

rajivnathan mentioned this pull request Apr 3, 2020

odo push trigger redeploy even if there are no changes in devfile #2662

Closed

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. Required by Prow. label Apr 3, 2020

openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. Required by Prow. label Apr 3, 2020

openshift-merge-robot merged commit fd8416c into redhat-developer:master Apr 3, 2020

maysunfaisal mentioned this pull request Apr 3, 2020

Fix sync when the pod gets re-created #2811

Merged

Devfile command execution #2735

Devfile command execution #2735

Conversation

maysunfaisal commented Mar 19, 2020 • edited

rajivnathan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maysunfaisal Mar 25, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maysunfaisal Mar 25, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maysunfaisal commented Mar 25, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kadel commented Mar 27, 2020

maysunfaisal commented Mar 27, 2020 • edited

rajivnathan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adisky left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johnmcollier left a comment • edited

Choose a reason for hiding this comment

kadel commented Apr 3, 2020

kadel commented Apr 3, 2020

openshift-ci-robot commented Apr 3, 2020

openshift-bot commented Apr 3, 2020

openshift-bot commented Apr 3, 2020

openshift-bot commented Apr 3, 2020

openshift-bot commented Apr 3, 2020

maysunfaisal commented Mar 19, 2020 •

edited

maysunfaisal Mar 25, 2020 •

edited

maysunfaisal Mar 25, 2020 •

edited

maysunfaisal commented Mar 25, 2020 •

edited

maysunfaisal commented Mar 27, 2020 •

edited

johnmcollier left a comment •

edited