* 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
