* Label ServiceBinding tests, so we can run them separately
They require installing additional components in the cluster (OLM, SBO, ...).
* Add GH Workflow for most of our tests (including cluster-related tests)
This allows to easily test even multiple versions of Kubernetes if needed.
For easier reporting and visualisation (and also avoid rebuilding odo many times),
Podman tests have also been relocated in this same Workflow.
Notes:
I tried to spin up lightweight OpenShift clusters but gave up because of several issues:
- MicroShift: I tried to use the aio container image, but this one is no longer maintained and is pretty old version of OCP.
Trying to follow the official guidelines did not work either because a base RHEL OS is mandatory
- CRC/OpenShiftLocal with Microshift preset: didnt pass the pre-checks because it detected an issue with nested virtualization on the GH Runner.
* Drop unused code in helper_oc and use namespace instead of project
When testing on Microshift, it seems that the Project API is purposely not implemented on MicroShift
* Revert using a DEVFILE_PROXY env var
There is no proxy deployed in the internal test cluster.
As such, this env var no longer makes sense.
* To help troubleshoot, display the resolved Devfile registry URL
* Make interactive tests more resilient with stack versions
They are now able to determine if the "Select version" prompt
should be asked by "odo init" or not:
* Make sure doc automation tests do not rely on hard-coded namespaces
* Allow to run doc automation tests with more parallel Ginkgo nodes
This is possible now that those tests no longer
depend on a single hard-coded namespace.
* Remove occurrences of the DEVFILE_REGISTRY env var in IBM Pipelines scripts
* Reuse logic for determining the Devfile Registry URL in "odo registry" tests
* Clarify what openshiftci-config.sh is used for
* Wrap warning messages to make them more visible
For example, instead of displaying:
```
⚠ You are using "default" project, odo may not work as expected in the default project.
```
We are now displaying:
```
========================================================================================
⚠ You are using "default" project, odo may not work as expected in the default project.
========================================================================================
```
* Display warning message about default project/namespace in a single block
* Add unit test
* Fix sample outputs for doc automation tests
* Revert "Fix sample outputs for doc automation tests"
This reverts commit 98a6554c34.
* Ignore '===' warning header and footer for doc automation tests
* Ignore devstate when existing process name is not odo
* Delete orphan devstate files with odo delete component
* Update unit tests
* Create fake system
* Add unit tests for odo delete component
* Integration tests for odo dev
* Troubleshooting
* First process on Windows is 4
* Use go-ps lib for pidExists
* Add integration test case highlighting the issue
* Make sure a Deploy command is present in the Devfile before auto-applying components
* Fix expected output in 'odo deploy' interactive tests
* Display Git commit ID in output of odo commands where the version is displayed
This covers:
- odo init
- odo dev
- odo deploy
Displaying the commit ID (same as in `odo version`) will help quickly pinpoint the exact commit without having to run `odo version`.
See #6131 for more context
* Append the state of the working tree next to the Git commit ID
`git describe` is much more helpful to quickly understand the state of the working tree.
For backward compatibility, we are defaulting to `git rev-parse`,
just in case `git describe` does not work correctly.
* Fix integration tests
* Fix doc automation tests
Strip the Git commit ID from the full odo version string
prior to comparing the outputs.
We still want to compare the tag displayed.
* Make sure to delete the namespace generated for the test
Otherwise, it might cause name collisions
upon several subsequent runs of the same tests.
* Be more resilient when trying to delete the namespace/project after each test
Do nothing if the namespace/project no longer exists
* Be more resilient when trying to create the namespace/project before each test
Eventually check the existence of the created namespace/project.
* Rename 'helper#GetProjectName' into 'helper#GenerateProjectName'
This makes the intent clearer.
* Make sure to always delete the random namespace/project created when testing project/namespace deletion
* Make UI not experimental
* Display API and UI URLs
* Remove link to old sources
* Fix integration tests
* Add UI to Usage Data
* Add a "Using the GUI to edit the Devfile" page to doc
* Add link to odo.dev specific page
* Apply suggestions from code review
Co-authored-by: Armel Soro <armel@rm3l.org>
* Change favicon with odo logo
* Display web console URL as part of the Dev status
* Update UI static files
* Document that Comments not supported
* Add UI screenshots
---------
Co-authored-by: Armel Soro <armel@rm3l.org>
* Remove kubeconfig flag
* Do not check file exists from KUBECONFIG, as KUBECONFIG can be a list of files and this is done by clientcmd library
* Fix odo --help
* Add integration test to check flag is not supported
* Remove API Server from experimental mode, set UI Server as experimental
* Adapt api-server integration tests
* Disable --api-server by default in the tests
They are enabled only if `options.StartAPIServer`
is explicitly enabled.
This is to avoid potential port conflicting issue,
especially on Windows - see [1]
[1] https://github.com/redhat-developer/odo/issues/6939
* Error out if `--api-server-port` is set but `--api-server` is false
---------
Co-authored-by: Armel Soro <asoro@redhat.com>
* Let the OS assign a random ephemeral port if `--random-ports` is specified when running `odo dev` or `odo api-server`
This should hopefully fix the potential port conflict flaky
issue we are seeing, especially on Windows.
* Do not allow setting `--random-ports` and a specific port value
This applies to:
- `odo dev --random-ports --api-server --api-server-port=<port>`
- `odo api-server --random-ports --port=<port>`
* refactor: Set the experimental mode env var in a single place for the '--api-server' related tests
* Add integration tests highlighting the expectations
* Make the state client return the API server ports per platform
'odo dev' might be running on both cluster and podman,
so we might end up with several API servers.
* Make 'odo describe component' return information about the API Server and web UI
This is viewable only when running 'odo describe component'
with the experimental mode enabled.
* fixup! refactor: Set the experimental mode env var in a single place for the '--api-server' related tests
* Unit-test describe#filterByPlatform logic
* Simplify logic for 'describe#filterByPlatform', as suggested in review
Co-authored-by: Philippe Martin <phmartin@redhat.com>
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Display the supported architectures in `odo registry` output
* Allow filtering by architectures
* Update documentation accordingly
* Add test cases
* fixup! Update documentation accordingly
* fixup! Allow filtering by architectures
Devfiles with no architecture declared are supposed to be compatible
with all known architectures.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* fixup! Add test cases
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add new `--run-port` flag to `odo init` to set ports non-interactively
As depicted in [1], this leverages the default (or single non-default) run command to find the linked container component.
As such, it assumes that the command found is an exec command,
and that the linked component is a container component.
[1] https://github.com/redhat-developer/odo/issues/6925
* Add unit and integration tests highlighting the expectations
* Document the new `--run-port` flag
* Fix some typos and language correctness issues in the `odo init` doc
* Add doc automation test for the output of `odo init --run-port`
This ensures the output and sample in the doc are kept in sync with the code base.
* Add integration tests highlighting the expectations
* Add and fill a 'Commands' field from the DevfileData struct returned by `describe`
* Display commands in the human-readable output of 'odo describe'
* Add documentation and sample outputs
* Fix issues in the tests if user does not have permission to see the OpenShift platform version
This happened on the nightly jobs running on Prow,
which makes us use a developer account with some restrictions.
* Rename 'helper.JsonSatisfies' into 'helper.JsonStatisfiesAll' to make the intent clearer
* Pass odo context to api server
* Get /instance
* DELETE /instance implementation
* Move describe logic to pkg/component/describe
* Get /component implementation
* POST /component/command implementation
* Fix example by replacing action with name
* Fix integration test
* Integration tests
* Add comment for PushWatcher
* Test DELETE /instance without --no-watch
* Apply suggestions from code review
Co-authored-by: Armel Soro <armel@rm3l.org>
* Return an error if not ready for push
* Fix windows tests
* Fix tests for Windows
---------
Co-authored-by: Armel Soro <armel@rm3l.org>
* Show podman version in odo version; TODO: fix test and implement json
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add integration test
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add support for JSON
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add documentation
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Fix missing OpenShift version
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add warnings when unable to fetch version information
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Do not print warning when --client is used and review
Signed-off-by: Parthvi Vala <pvala@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* check SKIP_SERVICE_BINDING_TESTS to skip service binding tests
* Pass SKIP_SERVICE_BINDING_TESTS to Windows for Windows tests
* Use fsGroup on Kubernetes
* add instructions to install devfile registry in cluster
* Add test highlighting the expectations
* Propagate errors and call os.Exit only in 'main' functions
See ExitInMain[1] and ExitInMain_ExitOnce[2] coding convention guidelines.
[1] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#exit-in-main
[2] https://github.com/redhat-developer/odo/wiki/Dev:-Coding-Conventions#exit-once
* Handle errors returned by Cleanuper#Cleanup
This makes sure the exit code of the command
is mapped onto any error returned by Cleanup
* Do not return an error when the watch loop in 'odo dev' is interrupted
* Test that the exit code of 'odo dev' matches the error returned by the cleanup logic
* Implement HTTP Server based on OpenAPI spec
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Starter server when odo dev starts
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add --api-server and --api-server-port flags to start API Server; write the port to stat file; TODO: make this feature experimental
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Make the flag experimental
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Make apiserver and apiserverport flag local
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use container image to run openapi-generator-tool instead of a local CLI
Co-authored-by: Armel Soro <asoro@redhat.com>
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add integration test
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use label podman
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Regenerate the api files with openapitool v6.6.0 and changes from review
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <asoro@redhat.com>
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Document the '--no-commands' flag
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add integration tests highlighting the expectations
* Add '--no-commands' flag to the 'dev' sub-command
* Implement '--no-command' on Podman
* Implement '--no-command' on cluster
* Validate the '--no-commands' flag in the CLI
For example, it should not be possible to call it alongside '--build-command' or '--run-command',
because we won't be able to know what to do.
* Fix 'odo dev' tests when the run/debug does not exist
For consistency with how e.g., the build command works,
instead of erroring out, `odo dev` will
now simply log the error message and wait for new input.
* Check for command existence when we want to run them
As suggested in review, this makes it more adaptable.
As a consequence, if the default (or single) build/run command does not exist,
"odo dev" will not error out immediately; instead, it will behave a bit like
"odo dev --no-commands" (by starting, but printing a warning about the
missing command).
The difference here is that if a run command is added later on
during the dev session, "odo dev" will pick it up and run it,
but "odo dev --no-commands" will continue to purposely ignore it.
The existence of the optional default Build is already checked
by the 'libdevfile.Build' command. It does not error out if there is
no default (or single) Build command. It errors out only if the specified
'--build-command' does not exist in the Devfile.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Check for application ports only if the Devfile has run or debug command and if there are ports to forward
This prevents:
i) displaying the "Waiting for the application to be ready" spinner for nothing,
if there are no ports to forward
ii) waiting until the timeout of 1m has expired if there was no run/debug command executed,
in which case, it is less unlikely that the application ports defined in the Devfile
will ever be reachable.
* Test "odo run" command against a Dev Session started with and without "--no-commands"
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Change NewRunHandler params with Options
* Pass an options to RunHandler to show logs
* Hide spinner and std output since outputs are displayed
* Integration tests with failing command
* Fix outputs
* use raw terminal and local standard i/o streams
* Fix podman i/o
* Fix stdout/err
* Test if in/out are terminal
* command reference doc
* Add a run command
* Check command name passed as arg
* Check platform is available
* Add a Run method to the DevClient
* Run command on cluster
* Add test with run command on cluster
* Implement and test run on podman
* Enhance test to check that command has been executed in container
* Fix `odo help` test
* Refactor common code for podman/cluster
* Test Apply commands on Kubernetes/Images
* Test a msg is displayed when executing odo run without odo dev
* Review
* makes GetRunningPodFromSelector return only Running pods on Podman
* Check that the "Syncing files into the container" spinner is correctly displayed on both Podman and cluster
* Add missing "Syncing files into the container" spinner when running 'odo dev' on Podman
This indicates to the user that we are sync'ing the files,
which might be a potentially long operation.
This is to be consistent with the output when using 'odo dev' on cluster.
* Add integration test highlighting the expectations
* Record parameter (and value) set or unset using the 'odo preference set/unset' commands
By default, values are anonymized.
Only parameters explicitly declared list will be recorded verbatim.
This list is currently empty, but that might change later on.
* Mark all current preference parameters except ImageRegistry as clear-text
Co-authored-by: Philippe Martin <phmartin@redhat.com>
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add integration test highlighting the expectations
* Use the cancellable context derived from 'cmd.Context' where needed
* Introduce new 'wasTelemetryEnabled' telemetry property
This is recorded before any command is run.
And it will help determine if telemetry was
changed (e.g., from enabled to disabled),
so that we can record the event in this case.
* Send telemetry if it was enabled previously or if it is currently enabled
This is done by reading the actual telemetry setting
(either from env vars or the preferences file)
at the moment we want to record the telemetry event.
This covers cases where a command ('odo preference set ConsentTelemetry')
or an environment variable ('ODO_TRACKING_CONSENT')
updated the telemetry consent for example.
* Document current implementations of command handlers
* Add unit tests for execHAndler
* Refactor pkg/devfile/image to inject Backend as dependency
* Use same handler for kubedev/podmandev
* Fail after SelectBackend==nil only if backend is needed
* Move runHandler to dev/common
* Unit tests for runHandler
* Create a component.ExecuteTerminatingCommand
* ExecuteTerminatingCommand/ExecuteNonTerminatingCommand for Handler
* Fix calling other command types
* Consider parent group to determine if a command is terminating
* Replace component.execHandler by common.runHandler
* Remove execHandler
* Make runHandler and most of fields private and pass containersRunning to handler
* Pass containersRunning value
* deploy using common Handler
* Fix tests
* Use specific Dev/Deploy mode for Apply
* Fix cmdline for job
* Fix unit tests
* Pass appName and componentName with ctx to handler
* Move handler to pkg/component package
* Update doc
* Unit tests Deploy
* Unit tests Build
* Unit tests Run
* Unit tests PostStart
* Unit tests PreStop
* Update doc
* Fix Podman tests
* Fix hotReload on podman
* Change podman version timeout to 30s for tests
* Cleanup + fix doc
