Release Ticket: v0.3.0 of e2e-framework

This is the third release of the 2023 after nearly four months of active contribution from the community. This release packs a great deal of interesting features, fixes, and documentation updates. Let's highlight some of the below.
Thread Safe Test Context
When Parallel test features where enabled and integrated into the framework, it was enabled with room for running into race conditions. In this release we have included changes that helps us mitigate these issues when the tests are being run in parallel.  This has been achieved by doing the following mechanism.

Populate the test context via the BeforeEachTest handler
Generate a child context from the parent context and provide that for individual tests/assessments
Discard the context from step 2 after the tests are done
Pass the original parent context to the AfterEachTest handler

As part of the said changes to mitigate the race condition, we also extended the Environment.Test and Environment.TestInParallel function to return a context.Context back after the execution of the tests have been completed. This also allows for better debugging of test context to analyze failrues better with the added advantage that this is not breaking any of the existing contracts. However, if you are using a golint infra and have errcheck linter enabled, you will have a make a few changes to your code to account for the newly returned value from the Environment.Test and Environment.TestInParallel functions.
Limitations

The Finish phase will only be able to see the context from the Setup phase and not the one from the features themselves.

Related Issues

https://github.com/kubernetes-sigs/e2e-framework/issues/216
https://github.com/kubernetes-sigs/e2e-framework/issues/258

Related Pull Requests

https://github.com/kubernetes-sigs/e2e-framework/pull/292

Continubutors
@phisco @maruina
FluxCD Integration
e2e-framework has had helm workflow integrated under the third_party support package for a while and now, we are adding FluxCD to that arsenal.  With this integration, now you can integrate your e2e tests to run against a repository using fluxcd constructs. The supported features include the following.

 One could bring up a new cluster using kind and run the e2e tests against them using the framework or integrate against a real cluster and run tests against them. In this release,
kwok is being added to that list of supported cluster providers.
Since kwok provided a simulated kubelet instead of running a real kubelet, this can helm create a cluster with large number of nodes with very quick turn around time, reducing the turn around time to run the e2e tests. With this support, end users of the framework can now standup a simple kwok based cluster and run their tests against it. This also supports discovering the kowkctl binary from non standard location in order to simplify the integration.
Releated Issues

https://github.com/kubernetes-sigs/e2e-framework/issues/214

Related Pull Requests

https://github.com/kubernetes-sigs/e2e-framework/pull/239

Contributors
@reetasingh
Support for Custom Binary Paths
With this release, e2e-framework provides a mechanism where by, end users can provide a custom path from where the binaries such as kwokctl, helm or kind can be discovered. This helps consumers of the framework who wants to keep their binaries in non standard path outside of the $PATH and consume them for the integration needs.
Related Issues

https://github.com/kubernetes-sigs/e2e-framework/issues/282

Related Pull Requests

https://github.com/kubernetes-sigs/e2e-framework/pull/286

Contributors
@harshanarayana
Cluster Provider Interface for easy inclusion of additional Cluster providers
Until now, e2e-framework had a series of custom built hand crafted helper functions defined under envfuncs that enabled end users to perform operation such as instanciating a new cluster, destoring a cluster, collecting logs etc. However, with the interest in adding additional cluster providesr such as kwok, k3d and possibly many others in the future, it became critical that we define a set of common interfaces that can be implemented by the provider so that
we can avoid having duplication in the code provided under envfuncs package. What started as a discussion during the review of kwok provider integration turned into a full blown feature to enable better integration of providers in the
future.
As part of this work, e2e-framework not provides an interface named E2EClusterProvider which can be implemented by any cluster provider that we want to integrate into the framework and the existing envfuncs can be used as is for the new provider without having to add new code to it.
Providers can also implement an additonal optional interface E2EClusterProviderWithImageLoader which extends the E2EClusterProvider and adds two more additional supported feature around being able to load a container image into the cluster. Either as individual images or as a archieve. (kind currenrly supports this workflow)
Deprecation
As part of this implementation, the following envfuncs have been deprecated and should be replaced with the respective alternative in the future.

GetKindClusterFromContext  can be replaced with GetClusterFromContext
CreateKindCluster can be replaced with CreateCluster
CreateKindClusterWithConfig can be replaced with CreateClusterWithConfig
DestroyKindCluster can be replaced with DestroyCluster
ExportKindClusterLogs can be replaced with ExportClusterLogs

Following section has a few example of what this replacement would look like. (Code snippets taken from examples)
Deprecated kind based Cluster setup
func TestMain(m *testing.M) {
    testenv = env.New()
	kindClusterName := envconf.RandomName("decoder", 16)
	testenv.Setup(
		envfuncs.CreateKindCluster(kindClusterName),
	)
	testenv.Finish(
		envfuncs.DestroyKindCluster(kindClusterName),
	)
    os.Exit(testenv.Run(m))
}

Suggested kind based Cluster Setup
func TestMain(m *testing.M) {
	testenv = env.New()
	kindClusterName := envconf.RandomName("decoder", 16)
	testenv.Setup(
		envfuncs.CreateCluster(kind.NewProvider(), kindClusterName),
	)
	testenv.Finish(
		envfuncs.DestroyCluster(kindClusterName),
	)
	os.Exit(testenv.Run(m))
}

Related Issues

https://github.com/kubernetes-sigs/e2e-framework/issues/245

Related Pull Requests

https://github.com/kubernetes-sigs/e2e-framework/pull/246

Contributors
@harshanarayana
Subresource Update support via the klient's resources package
klient's resources not supports a few new helper method that are aimed towards updating the sub resources.

func (r *Resources) UpdateSubresource(ctx context.Context, obj k8s.Object, subresource string, opts ...UpdateOption) error {}
func (r *Resources) UpdateStatus(ctx context.Context, obj k8s.Object, opts ...UpdateOption) error {}
func (r *Resources) PatchSubresource(ctx context.Context, obj k8s.Object, subresource string, patch k8s.Patch, opts ...PatchOption) error {}
func (r *Resources) PatchStatus(ctx context.Context, objs k8s.Object, patch k8s.Patch, opts ...PatchOption) error {}

These new helper functions make it very easy to interact with subresources as part of your e2e-framework based tests
Related Pull Requests

https://github.com/kubernetes-sigs/e2e-framework/pull/249

Contributors
@wzshiming
Other notable changes

Updated kubernetes component dependency to v1.27.x by @harshanarayana in https://github.com/kubernetes-sigs/e2e-framework/pull/244
Enabled ability to use --labels where the selectors have the same key (i.e --labels="feature=foo,feature=bar") by @embano1 in https://github.com/kubernetes-sigs/e2e-framework/pull/248
Added support for DeploymentAvailable condition check helper by @ryankwilliams in https://github.com/kubernetes-sigs/e2e-framework/pull/251
Enhanced example for using namespaces passed to the test via context by @maruina in https://github.com/kubernetes-sigs/e2e-framework/pull/253
Improved error reporting for kind Cluster provided by @mmanciop in https://github.com/kubernetes-sigs/e2e-framework/pull/256
Improved error result for helm command workflows by @bradbeam in https://github.com/kubernetes-sigs/e2e-framework/pull/262
Improvoed conversion of resource handler options properly between metav1 and controller-runtime by @harshanarayana in https://github.com/kubernetes-sigs/e2e-framework/pull/278
Enabled linters on examples along with actual code by @harshanarayana in https://github.com/kubernetes-sigs/e2e-framework/pull/281
Added documentation about e2e-framework adopters by @vladimirvivien in https://github.com/kubernetes-sigs/e2e-framework/pull/285
Added support for adding descriptions under table driven test definition model by @harshanarayana in https://github.com/kubernetes-sigs/e2e-framework/pull/284
Removed unused random source seeding property by @matrus2 in https://github.com/kubernetes-sigs/e2e-framework/pull/294
Enabled Github Issue and PR templates by @harshanarayana in https://github.com/kubernetes-sigs/e2e-framework/pull/298
Enabled printing the stacktrace when the graceful teardown mode is enabed by @reetasingh in https://github.com/kubernetes-sigs/e2e-framework/pull/299

New Contributors

@phisco made their first contribution in https://github.com/kubernetes-sigs/e2e-framework/pull/292
@wzshiming made their first contribution in https://github.com/kubernetes-sigs/e2e-framework/pull/249
@ryankwilliams made their first contribution in https://github.com/kubernetes-sigs/e2e-framework/pull/251
@mmanciop made their first contribution in https://github.com/kubernetes-sigs/e2e-framework/pull/256

Special Thanks
A special thanks to @cpanato, @ShwethaKumbla and @vladimirvivien for their incredible and continued support by providing valuable suggestions during the change reviews and their continued work in making sure the dependencies are upto date with the help of dependabot.
Full Changelog: https://github.com/kubernetes-sigs/e2e-framework/compare/v0.2.0...v0.3.0

I have uploaded a draft copy of the change log for the release cut for v0.3.0. Since this release will have a large set of new features/changes, based on discussion with @vladimirvivien, updating the tag to v0.3.0 instead of bumping to version to v0.2.1.
Please take a look.
/assign @ShwethaKumbla  @cpanato @vladimirvivien @spiffxp @andrewsykim @BenTheElder @alejandrox1

WOW! What a release!!!
nit: klient's resources not supports -> "now supports"

@harshanarayana this is awesome.

@harshanarayana This is great!!
observed some nit :
section "Thread Safe Test Context"
 .....to analyze failrues --> to analyze failures
you will have a make a --> you will have to make a
section "Other notable changes"
7. Improvoed  --> Improved
13.  .... mode is enabed by --> mode is enabled by

Thanks @ShwethaKumbla @embano1. Updated the description as per the comments

/close
Thanks @vladimirvivien for taking care of the release workflow


Allow zoom change via Ctrl+Scroll

Add a possibility to change zoom using scroll and pressing ctrl button
#184086808

@Nitvex
@Iogsotot
Iogsotot
Hi there, just found a issue related with this task. Could you please take a look on it? Thanks!
This affects the R-Group creation because the 'initEditor' could not be dispatched correctly with the 'getState' param


Delete ara dir on job start

We want to have a clean slate when we trigger ara. As we are
storing everything in the WORKSPACE, we are safe to delete the dir
This fixes having a really big ara db on long running branches

Wait. Workspace is create per-job, right? So how could ARA dir exist when you (re)start a job?

Master and long running branches do not remove the workspace.

In regards to that, that comes from https://github.com/SUSE-Cloud/automation/blob/master/jenkins/ci.suse.de/templates/cloud-socok8s-integration.yaml#L72
but Im not sure why it was added and Im wary of touching the jobs again as they broke last time...maybe I should just try it.

I created https://github.com/SUSE-Cloud/automation/pull/3680 to see if it can be fixed like that

I thought periodics and all jobs would be in a different workspace, due to build id differing. Is build ID wrong? Maybe I misunderstood this.

It is, seems like build id is not used, only build name, so workspace for those are for example:
WORKSPACE=/home/jenkins/workspace/cloud-socok8s-daily-airship-integration

I thought periodics and all jobs would be in a different workspace, due to build id differing. Is build ID wrong? Maybe I misunderstood this.

It is, seems like build id is not used, only build name, so workspace for those are for example:
WORKSPACE=/home/jenkins/workspace/cloud-socok8s-daily-airship-integration

wouldn't that be the problem to solve?

wouldn't that be the problem to solve?

This problem should be already solved by https://github.com/SUSE-Cloud/automation/pull/3680 so this should be closed, Im just waiting for confirmation.
But indeed it doesnt seem sane to reuse the same environment. If we go with build ids, then we need to clean the workspace at the end of the job always as to not leave stuff around. And Im very weary of touching anything jenkins related anymore as to not break it.

not needed anymore as https://github.com/SUSE-Cloud/automation/pull/3680 fixed it


How do I filter files?

It looks like the configuration file does not provide a mechanism to filter the fileset with filter. Is there a way to do that? currently, it seems to look up for target/class/build.properties for that.

can you clarify your question? filtering works via the assembly configuration if you've enabled the flag.

I can turn the filtering on. I just would like to specify the filter.properties file it should use.

It use the Maven properties defined in the pom. You can read in properties with the maven-properties-plugin if this is what you want.

Does not seem to work... I got the following exception:
Caused by: java.io.IOException: Error filtering file 'java.io.InputStreamReader@3cb8c8ce': Error loading property file '.../target/classes/build.properties'
at org.apache.maven.plugin.assembly.format.ReaderFormatter$1.transform(ReaderFormatter.java:134)
at org.codehaus.plexus.components.io.resources.AbstractPlexusIoResourceCollection.getInputStream(AbstractPlexusIoResourceCollection.java:279)
at org.codehaus.plexus.components.io.resources.Deferred.(Deferred.java:45)
at org.codehaus.plexus.components.io.resources.AbstractPlexusIoResourceCollection.resolve(AbstractPlexusIoResourceCollection.java:286)
at org.codehaus.plexus.archiver.ArchiveEntry.(ArchiveEntry.java:74)
... 40 more

sounds like i have to add

...

${basedir}/src/main/docker/environment.properties

...


EfficientnetB1 :ValueError: You are trying to load a weight file containing 185 layers into a model with 184 layers

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information
yes- Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
Colab - OS Platform and Distribution (e.g., Linux Ubuntu 16.04):

Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
Source- TensorFlow installed from (source or binary):
TensorFlow version (use command below):
3.6- Python version:
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
after using your code efficientnet_weight_update_util.py to  converted pretrained weights model.ckpt to efficientnetb1_notop.h5
please help, im getting the mentioned error
model = EfficientNetB1(weights="efficientnetb1_notop.h5", include_top=False)
Describe the expected behavior
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab notebook.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

@gunjan5489
Please share simple indented stand alone code to replicate the issue faced along with error logs, or if possible share a colab gist with the same.


Signature Algorithm Not Matched to Key on Issue#356

Solve the first problem in Issue #356

Coverage remained the same at 97.952% when pulling bf550835f4b3d9d61b8881593b9fcd28443ab148 on FelixWang1994:develop into 6fde6222c9c6abf905ef4a56cf56fe35c4a85e14 on theupdateframework:develop.


Support for QuPath 0.5 and local models

Resolves #32

Local model support implemented, whenever the user directory is changed we scan for directories, and add them based on the folder name. Invalid entries pop up a notification, otherwise models should work as for online models, at least based on my running a modified version of a remote model
Disabled checking modification times and checksums because that seems unnecessary for user models.

@alanocallaghan can you briefly explain how to use this?
Put what files where...?

Feels like a picture paints a thousand words. my_model pops up in the searchable combobox and works like any other model

The "user directory" refers to the "User model directory" in the WSInfer extension window

fantastic! :rocket:

Fantastic indeed! Can confirm this also works with home-built models and custom config.json. Another great upgrade—thanks!

Great that it works!
Question to all: Would it be a good or bad idea to just use one model directory, and not store user models somewhere else?
The main reasons for:

Simpler
On a small (e.g. 13" laptop) monitor, the current dialog is sometimes too tall... so we need to solve a vertical space problem if we can't shrink it somehow

Main reason against (that I can think of):

Potentially overwriting user models if there are name clashes

Great that it works!
Question to all: Would it be a good or bad idea to just use one model directory, and not store user models somewhere else?
The main reasons for:

Simpler
On a small (e.g. 13" laptop) monitor, the current dialog is sometimes too tall... so we need to solve a vertical space problem if we can't shrink it somehow

Main reason against (that I can think of):

Potentially overwriting user models if there are name clashes

Could just have a "user" subdirectory thats checked automatically, and ensure no model named user is ever added to the model zoo

Personally a single directory is what I was expecting. In fact I had added my models to an acaputo directory that was a sibling of the kaczmarj directory for the default (zoo) models.
Regarding your concern:

On a small (e.g. 13" laptop) monitor, the current dialog is sometimes too tall

If I understood correctly, I don't think this is going to be much of a problem because I would advise anyone with more than 6–8 models to use the text filtering capabilities of that dropdown.

Question to all: Would it be a good or bad idea to just use one model directory, and not store user models somewhere else?

i think it is a good idea to have just one model directory, because then there will be a single source of truth. this would simplify the user experience imho.
if this isn't part of the extension yet, it might be useful to have a button that opens a file browser to the model directory. although i hope users wouldn't fiddle around with the downloaded models, which could break something ;)
i wanted to add some info to one point:

In fact I had added my models to an acaputo directory that was a sibling of the kaczmarj directory for the default (zoo) models.

just for clarity, the kaczmarj directory is created because that's my huggingface username, and all of the models in the zoo so far are on my huggingface account.

This is a fantastic feature!
Are there any plans to include this on the Qupath site or the Use your own model section of the WSInfer site? Or is the documented elsewhere and I have just missed it?

it isn't on the qupath site, but it should be. @sandyCarmichael - would you be interested in submitting a pr that adds these steps to the qupath documentation?

Hey @vipulnj, indeed the steps for this process have changed since this pull request. The updated process is detailed in #48, basically:

Find the downloaded model directory
Create a "local" or "user" directory in that folder
Add models as subdirectories of the "local"/"user" directory
Hey presto

Do let us know if there's any issues with that process

Hi, I am on Mac M1, Qupath 0.5.1, WSInfer 0.3. I tried to add a local model (which I  tested on WSInfer command line) but no success. I tried local and user both as sibling and as descendant of kaczmarj in the models directory. I also restarted Qupath after every change. What I am doing wrong? thanks.

Hi, I am on Mac M1, Qupath 0.5.1, WSInfer 0.3. I tried to add a local model (which I tested on WSInfer command line) but no success. I tried local and user both as sibling and as descendant of kaczmarj in the models directory. I also restarted Qupath after every change. What I am doing wrong? thanks.

The model should definitely be as a sibling of kaczmarj. Can you provide a screenshot of the model directory, showing the overall structure of the user model directories and files?

Here it is, thanks. I also tried to have the main folder inside the model folder.

Do you see any messages in the log viewer when opening WSInfer with this setup?

Apologies for not having checked the log before (never had need, I did even not know where to look for :) ). Yes, it expects a model specifically named torchscript_model.pt . After having renamed it, it is recognised.
However, then I have another issue so the model is not running. This is notified by a WSinfer dialog as follows (it is much longer, I even cannot read it all). Maybe it has to do with how I created it, however it runs from command line. There are two warnings in the log also:

11:58:06.66	[JavaFX Application Thread]	WARN	qupath.ext.wsinfer.models.WSInferUtils	Replaced model breastcancer with local version
11:58:16.405	[wsinfer1]	INFO	qupath.ext.wsinfer.WSInfer	Attempting to set device to mps
11:58:16.406	[wsinfer1]	WARN	ai.djl.repository.SimpleRepository	Simple repository pointing to a non-archive file.
11:58:16.432	[Finalizer]	WARN	ai.djl.BaseModel	Model: torchscript_model was not closed explicitly.

This error is vaguely familiar but I can't remember exactly what caused it before. There are some DJL and Pytorch related issues:

https://github.com/deepjavalibrary/djl/issues/2474
https://github.com/pytorch/pytorch/issues/71402

that might help?

Thanks, not yet able to solve that, anyway I submitted a pull request for the docs related to the Qupath extension so the basics are documented.

Thanks! Alternative may be to run the model on CPU for now

well, not really: also on CPU it does not run, same error. (Zoo models run).
I am not in a hurry, I will find a solution.

can you try transferring your model to cpu before exporting it to torchscript? some pseudo-code to illustrate what i am thinking:
model.eval()
model.cpu()

# Add other arguments as needed.
model_jit = torch.jit.script(model)

torch.jit.save(model_jit, "torchscript_model.pt")

then i think the model should work on cpu or gpu.... fingers crossed 🤞

@kaczmarj : thanks, this plus some magic found on Stack Overflow solved the issue (I have yet to consolidate & understand what I did, but now it runs :) ).


export withTranslation as an independent function

issue
Fixes #410
This is just a dumb proposal for the issue above.

There's also a conflict to resolve.

Sorry for the messy commits. I can (or you can) squash commits when all is fine.

No problem, we always squash merge!


Allow setting webpack mode to "development" in tests

Ruby version: 3.1.2
Rails version: 7.0.3
Shakapacker version: 6.2.1
JS debugger statements are useful, including when debugging system tests. But in test environment Shakapacker sets webpack to mode: 'production' which strips debugger statements.
Have you considered providing an option in webpacker.yml to set mode to development in test environment, to avoid a custom webpack config override?
Or perhaps tests should run with webpack mode: 'development' by default? As the builds are faster, with sourcemaps etc.?

Thanks for raising @AlecRust My take on this is trying to get test environment in the closest state to the production one, hence applying same optimisations. I do see your point around debugging though.
Adding webpack override should be fairly simple although it could use a recipe in the readme maybe to show people how to do it.
I think in general our aim for v7 will be streamlining the config to get this leaner and more customisable and through that we might make things like selecting mode bit easier. With that, I would prefer not adding anything new into webpacker.yml.
What's your take @justin808 ?

Somewhat relevant: if dev server is running, then webpacker skips compilation and so you get both mode: development and source maps in tests. As well as faster test startup.
This wasn't obvious to me until I started reading source code. Perhaps it would be worth mentioning this in the docs.

Whether or not this should be in the webpacker.yml would depend on whether or not we can say that the webpack mode should correspond to the RAILS_ENV.
Historically, the NODE_ENV was used to set a particular webpacker configuration file. We removed that in v6.
@artemave if you can submit a doc PR, we'll review it very quickly.

Closing as stale

We've been doing some experiments using the webpack-dev-server for RAILS_ENV='test' and it seems to work well.
It looks something like this.
# Note: You must restart bin/webpacker-dev-server for changes to take effect
default: &default
  # other settings
   compile: false
development:
  <<: *default

   # Reference: https://webpack.js.org/configuration/dev-server/
   dev_server: &dev_server
     https: false
     host: <IP_ADDRESS>
     port: 3035
    # Hot Module Replacement updates modules while the application is running without a full reload
    hmr: true
    inline: true
    client:
      # Should we show a full-screen overlay in the browser when there are compiler errors or warnings?
      overlay: true

    compress: true
    # Note that apps that do not check the host are vulnerable to DNS rebinding attacks
    allowed_hosts: [ 'localhost' ]
    pretty: true
    headers:
      'Access-Control-Allow-Origin': '*'
    static:
      watch:
        ignored: '**/node_modules/**'

 test: &test
   <<: *default

   dev_server:
     <<: *dev_server

 production:
   <<: *default
   cache_manifest: true

First start the weback-dev-server with:
RAILS_ENV=development NODE_ENV=development bin/webpacker-dev-server
Then start your server for development like NODE_ENV=development RAILS_ENV=development rails s.
Then you can run a test in development mode by:
RAILS_ENV=test NODE_ENV=development rspec
For CI, you can precompile assets with:
NODE_ENV=production RAILS_ENV=test bin/webpacker

@Judahmeek plans to add an example of this to https://github.com/shakacode/react_on_rails_demo_ssr_hmr/issues/32.

@tomdracz per your comment above, I think it's worth distinguishing local testing (webpack-dev-server, fast is good!) and CI testing where we precompile assets and should use a NODE_ENV=production (not test).
@tomdracz would you favor changing the default install files per the above addition of the dev_server to the test env?

The main issue with using the webpack-dev-server for tests is that the JS code will have embedded JS to so that the browser talks to the webpack-dev-server via web sockets, and that can cause all sorts of unnecessary and unexpected complications, especially if using different docker containers the different processes in terms of configuration of networking.
@tomdracz I'd love your thoughts on this one.
For now, keep the test and development modes separate!

Another use case to consider is using separate Docker containers for the webpack-dev-server and the Rails server, and running the browser on localhost.


Encountered error while trying to install package mplcairo with Python 3.10.6

It seems that the package mplcairo is not supported for Python 3.10.*
error: subprocess-exited-with-error
× Running setup.py install for mplcairo did not run successfully.
│ exit code: 1
note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure
× Encountered error while trying to install package.
╰─> mplcairo

Hence we should address #7 and remove the dependency or install it only on Python <= 3.9

With the release of mplcairo 0.5.0 this should be working. Can you confirm @valizadehm ?


Firewall Logs Widget - Settings Form Layout

Options labeling and arrangement
Space utilization

Update: Tweak column and select element widths for alignment and fitment.

@NOYB thanks!


Upload exploded archive

It'd be great to use this tool to upload a zip to be exploded in a sub-path of a repo, rather than using Curl or using the UI Deploy to a dummy repo then moving the content to the real location.

Thanks for this @jgeorgeson. We would like add this enhancement to one of the future versions of the JFrog CLI.
JFrog CLI is an evolution of the Artifactory CLI and we threfore recommend migrating to JFrog CLI if you hadn't done so already.

I will submit this to jfrog-cli


grpc_transcoder: check response transcoder error

Signed-off-by: Wayne Zhang<EMAIL_ADDRESS>To fix https://github.com/envoyproxy/envoy/issues/21490
grpc response transcoder will fail with error if the proto message is too deep (>64),  but grpc_transcoder filter encodeData() function did not check the error status.  This pr adds code to check the error status and adds a test.
Risk Level:  Low
Testing:  Unit-test
Docs Changes: No
Release Notes: Yes

/assign @lizan
as code-owner/maintainer