* 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
* Fix 'odo dev' tests by randomizing some missing component names
* Force setting a component name when copying example Devfiles
This way, we won't forget about this in the future.
* Use odo logo instead of author image in blog posts
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Update .github/workflow-data/release-management/blog-post-header.tpl.md
* Add image to all the blog posts
Signed-off-by: Parthvi Vala <pvala@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Do not error out in port detection if any of `/proc/net/{tc,ud}p{,6}` files are missing
/proc/net/{tc,ud}p6 files might be missing if IPv6 is disabled in the host networking stack,
as reported by a user on RHEL.
Actually /proc/net/{tc,ud}p* files might be totally missing if network stats are disabled.
* Do not error out if we are not able to detect container ports bound on the loopback interface
We are already displaying a warning in such case
(saying that port forwarding might not work correctly);
so this should not prevent port-forwarding messages to be displayed.
We are already behaving this way when detecting if endpoints in the Devfile
are actually opened in the container.
A warning is displayed if any error occurs while checking this.
* fixup! Do not error out in port detection if any of `/proc/net/{tc,ud}p{,6}` files are missing
* Replace deprecated '--slow-spec-threshold' Ginkgo flag with '--poll-progress-after'
Per [1], this instructs Ginkgo to automatically emit a progress report
whenever a node takes too long to complete.
The Progress Report includes information about which node is currently running
and the exact line of code that it is currently executing,
along with any relevant goroutines that were launched by the spec.
[1] https://onsi.github.io/ginkgo/#getting-visibility-into-long-running-specs
* Also set '--poll-progress-interval' flag so as to get progress reports periodically
* Add integration tests highlighting our expectations
* Bump Devfile library to latest commit
f041d79870
* Expose preference that allows users to globally configure an image registry
* Return the effective Devfile view by default from the initial context
This is supposed to be read-only, so that tools can rely on it
and to the operations they need to perform right away.
Raw Devfile objects can still be obtained upon request
if there is need to update them (for example via 'odo add/remove
binding' commands.
* Pass the image registry preference to the Devfile parser to build the effective view
* Fix 'odo init' integration tests
- The test spec was actually not doing what it was supposed to do
- Now 'odo init' returns a complete Devfile, where the parent is flattened,
because the goal of 'odo init' is to bootstrap a Devfile.
Previously, 'odo init' would not download the parent referenced,
making it hard to understand the resulting Devfile.
* Document how odo now handles relative image names as selectors
* fixup! Document how odo now handles relative image names as selectors
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Revert "Fix 'odo init' integration tests"
This reverts commit 78868b03fd.
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Do not make `odo init` return an effective Devfile as a result
This would change the behavior of `odo init`.
Furthermore, due to an issue [1] in the Devfile library,
it is not possible to parse some Devfiles with parents linked as GitHub URLs (like GitHub release artifacts).
[1] https://github.com/devfile/api/issues/1119
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* fixup! Document how odo now handles relative image names as selectors
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Add test highlighting the issue and setting the expectations
* Add a timeout of 1s to the 'podman version' command
This command is called at dependency injection time to initialize a (nil-able) Podman client,
even if users won't use Podman at all.
As discussed, this command is supposed to be
quite fast to return, hence this timeout of 1 second.
Initially, we were using cmd.Output to get the command output,
but as reported in [1], cmd.Output does not respect the context timeout.
This explains the workaround of reading from both stdout and stderr pipes,
*and* relying on cmd.Wait() to close those pipes properly when the program exits
(either as expected or when the timeout is reached).
[1] https://github.com/golang/go/issues/57129
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* Log the errors returned at dependency injection time when the optional Kubernetes/Podman clients could not be initialized
This helps debug such potential issues instead of swallowing the errors.
* Make the timeout configurable via the 'PODMAN_CMD_INIT_TIMEOUT' env var
This will allow setting a different value for environments like
in GitHub where the Podman client would take slightly more time to return
(I guess because of we are running a lot of Podman commands in parallel?).
* Increase the timeout for Podman tests to an arbitrary value of 10s
Some tests did not pass because the Podman client did not
initialize in 1s; I guess because we are running a lot of Podman commands in parallel?
This should hopefully improve this situation.
* fixup! Add a timeout of 1s to the 'podman version' command
---------
Co-authored-by: Philippe Martin <phmartin@redhat.com>
* On cluster, run Build command again only if Build command itself is not hotReloadCapable
* On Podman, execute Build command only if itself is not hotReloadcapable
* Handle hotReloadCapable in handler
* Add integration tests
* Update doc
* review
* Allow passing extra build flags to Podman/Docker
This is supported via 2 new env vars:
- ODO_IMAGE_BUILD_ARGS: passed when building images via Podman/Docker
- ODO_CONTAINER_RUN_ARGS: passed when running odo dev on Podman
Those are comma-separated list of options
that can be passed to either Podman or Docker
(depending on the PODMAN_CMD env var).
* Refactor 'build-images' tests to make it easier to add additional tests
* Add integration tests for passing build extra args
* Add integration tests for passing global extra args to Podman
* Distinguish between global options passed to Podman and specific options for 'podman play kube'
Previously, we were handling 'ODO_CONTAINER_RUN_ARGS' as global options for Podman,
but this turns our not being that useful if we want to pass dedicated options to 'podman play kube'.
This commit introduces a new 'ODO_CONTAINER_BACKEND_GLOBAL_ARGS' env var,
which will be used as global options passed to every Podman command we execute.
This paves the way to isolating our Podman-related tests further
using the '--root' and '--runroot' global options.
* Use `ODO_IMAGE_BUILD_ARGS` in the Advanced Guides
* Use a semicolon as delimiter for extra flags
Doing so because some of the options of Podman/Docker can actually be either repeated or comma-separated.
* Custom address for port forwarding
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add integration tests
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use private variables for custom address and ports
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Update pkg/util/util.go
Co-authored-by: Armel Soro <armel@rm3l.org>
* Assign custom address to HostIP for podman
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add validation for free port when --port-forward is provided in the Validate() method, add integration test for running parallel dev sessions on same platform, same port and different addresses
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Fix unit test failure
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Attempt at fixing windows failure
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Add documentation
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Use default value for --address flag
Signed-off-by: Parthvi Vala <pvala@redhat.com>
* Changes from review
Co-authored-by: Armel Soro <asoro@redhat.com>
Signed-off-by: Parthvi Vala <pvala@redhat.com>
---------
Signed-off-by: Parthvi Vala <pvala@redhat.com>
Co-authored-by: Armel Soro <armel@rm3l.org>
Co-authored-by: Armel Soro <asoro@redhat.com>
* Same signature for reconcile in kubedev/podmandev
* Do not call initial reconcile
* Do not retry + filter deployment events
* Integration tests
* Move logs back to level 4
* Remove unnecessary files
* Log state + Set state to ready when build fails
* Get values from context
* Move Devfile param to WatchParams and biuld adapter only once
* Move pkg/devfile/adapters/kubernetes/* into pkg/dev/kubedev
* Rename Push to reconcile and split in 2 parts: components and innreloop
* Pass out ans errout as startOptions
* Embed StartOptions into PushParameters
* Embed StartOptions into WatchParameters
* Fix passing startoptions
* Deduplicate options (out, ...)
* Revert adding unwanted files
* Fix wait app ready
* Fix flaky test using custom port mapping when running specs in parallel
Using a global counter currently does not work
because Ginkgo runs parallel specs by isolating them in
completely different processes [1].
This relies on the parallel process index returned by Ginkgo
to get a value that can be used as starting port.
Callers can then safely increment this value if needed in the
specs to get a different custom value.
[1] https://onsi.github.io/ginkgo/#mental-model-how-ginkgo-runs-parallel-specs
* Apply suggestions from code review
Co-authored-by: Parthvi Vala <pvala@redhat.com>
* fixup! Apply suggestions from code review
---------
Co-authored-by: Parthvi Vala <pvala@redhat.com>
In those examples, the build and run commands are running in
different container components.
Without mounting sources in the container used for the 'run' command,
this command will not start because Maven would not be able
to resolve the 'spring-boot' plugin:
```
✓ Building your application in container (command: defaultbuild) [39s]
• Executing the application (command: defaultrun) ...
✗ Finished executing the application (command: defaultrun) [151ms]
⚠ Devfile command "defaultrun" exited with an error status in 20 second(s)
⚠ Last 100 lines of log:
✗ Waiting for the application to be ready [1m]
⚠ Port forwarding might not work correctly: timeout while checking for ports; ports not listening: (8080 in container "runtime"): context deadline exceeded
⚠ Running `odo logs --follow` might help in identifying the problem.
- Forwarding from 127.0.0.1:20001 -> 8080
```
This was not caught in the tests because failing to run the
'run' command current does not prevent the Dev session from starting.
This change might actually make the test faster as we would not have to wait 1 minute
to find out that the application port is not reachable.
