Bug Report: Issue with next-css-obfuscator in Next.js 15.0.0 Using app router

Bug Report: next-css-obfuscator Causes Unexpected SyntaxError in Next.js 15.0.0 with Middleware and Obfuscation
Type

[ ] Incorrect Class Name Extraction
[x] Incorrect JavaScript Obfuscation
[ ] Incorrect HTML Obfuscation
[ ] Incorrect CSS Obfuscation
[ ] Others

Checklist

[x] Updated the package to the latest version.
[x] Read all documentation.
[x] No related issue found.
[x] Meaningful issue title provided.

Environment

Package Version: v0.0.0
Node Version: v20.x.x
Next.js Version: 15.0.0
Others: Using app router with dynamic routing and middleware.

Describe the Bug
When applying next-css-obfuscator to a Next.js 15.0.0 project, dynamic routes using middleware and app directory structure fail with a SyntaxError: Unexpected strict mode reserved word.
The error occurs specifically in:
originalRequire.call(this, request);

Observed Behavior

On the client-side, the application displays a 500 Internal Server Error.
Server-side logs show:⨯ SyntaxError: Unexpected strict mode reserved word
    at <unknown> (...\.next\server\app\(customPage)\page.js.js:1)
    at mod.require (\node_modules\next\dist\server\require-hook.js:65:28)
    at requirePage (\node_modules\next\dist\server\require.js:103:84)
    at loadComponentsImpl (\node_modules\next\dist\server\load-components.js:100:57)

The issue seems related to obfuscation changing the syntax in strict mode.

To Reproduce
Steps to reproduce the behavior:

Create a Next.js app using version 15.0.0.
Configure middleware to redirect /page/[pageId] to src/app/(customPage)/page.tsx.
Apply next-css-obfuscator to the project with the following configuration:// next-css-obfuscator.config.cjs
module.exports = {
  enable: true,
  mode: "random",
  refreshClassConversionJson: false,
  allowExtensions: [".jsx", ".tsx", ".js", ".ts", ".html", ".rsc"],
  blackListedFolderPaths: [
    "./.next/cache",
    /\.next\/server\/pages\/api/,
    /_document..*js/,
    /_app-.*/,
    /__.*/, // <= helpful for Local Fonts
  ],
};

Run the app and navigate to a dynamic route, e.g., /page/123.

Expected Behavior

Dynamic routes should render correctly, and middleware should work as expected.
Obfuscation should not break syntax or interfere with Next.js runtime.

Screenshots
N/A

Configuration
// next-css-obfuscator.config.cjs
module.exports = {
  enable: true,
  mode: "random",
  refreshClassConversionJson: false,
  allowExtensions: [".jsx", ".tsx", ".js", ".ts", ".html", ".rsc"],
  blackListedFolderPaths: [
    "./.next/cache",
    /\.next\/server\/pages\/api/,
    /_document..*js/,
    /_app-.*/,
    /__.*/, // <= helpful for Local Fonts
  ],
};

Related Files

Dynamic Route File: Located at src/app/(customPage)/page.tsx.
Middleware: Handles redirection for /page/[pageId].

Dynamic Route Example
import { notFound } from "next/navigation";
import { Metadata } from "next";

export async function generateMetadata({ searchParams }: any): Promise<Metadata> {
  return {
    title: "Dynamic Page",
    description: "This is a dynamically generated page.",
  };
}

const MyPage = async ({ searchParams }: { searchParams: any }) => {
  const { pageId } = searchParams;

  if (!pageId) {
    notFound();
  }

  return <PageUI pageId={pageId} />;
};

export default MyPage;

Additional Context

The issue might be related to how obfuscator modifies or interacts with dynamic imports, require hooks, and middleware in the new app router.
Disabling ppr = true does not resolve the issue.
Ignoring src/app in obfuscator settings also causes unrelated folders like src/ui to be skipped for obfuscation.

An investigation will begin shortly (but most likely won't be in this month)

@nhannt201 Thank you for sponsoring!

I don't see any problem with my reproduction
To run the reproduction,
npm i && npm run build && npm run obs && npm run start

I used an additional layout layer to wrap the children, and outside of the children and WrapperComponent, I used MUI combined with TailwindCSS for handling. However, I encountered the above error. The issue is that sometimes it occurs in my project, and sometimes it doesn't. I also tried to reproduce it again, but I haven't been successful so far. Perhaps I will close the issue here and reopen it if I can reproduce the error along with the accompanying source. Thank you for your support.
But it seems like the className from MUI UI or other libraries cannot be transformed, except for modules with TailwindCSS.


Use View.animate

this updates the code using view.animate instead of ol.animation
this does update the dependency for ol to v3.20.0
Closes  #6

Replaced by #8.


Fixed outbrain regex

Considering all regex patterns are non-anchored, there is no reason to prefix any pattern with .*. Fortunately there is only one such pattern with this prefix.

Good spot. Thank you


Feature Request - RGB-Strip simulation instead of "just" a light

First - a big shoutout to your work! Your code is the only one, that worked as expected. Thanks alot!
So, now the feature request: Is there a way to implement RGB-Strip support? At the moment i see only a possible work-around: add devices with names red, blue, yellow and so on and hardcode the color in each callback-function.
But it would be much easier if the simulated device could set as an RGB-Strip instead of a Light with just the brightness-mode. Only say: alexa, set the color of "devicename" to red.... for example.
Here are so many smart heads - do someone have an idea to realize that?

I don't see the problem with treating each color (red, green & blue (& for some strips white)) as a different device. @Aircoookie is allowing up to 20 devices.  You could then say "set blue to 20%", "set red to 80%" & "set green to 80%" to get yellow.  Or, you could program Alexa to do a "macro" (I forget what this is really called) and just say "Alexa, I want it yellow" and have Alexa execute these 3 steps  to turn your strip yellow.  And, yes, for every color you would need to enter a new phrase and set of commands.

Hello,
thank you so much for this library!! I tried a few others but this is the only one that worked for me!
I have applied the fix you suggested in this issue and the system is now working with esp8266 core version 2.4.2.
However I am experiencing an issue. I have got 3x esp devices (adafruit Huzzah) each with 2 to 4 emulated devices loaded with your code. Four of these devices are programmed to do exactly what @st2000 has suggested to control an RGB strip (I also put there a white option to control all colors at once). The esp then sends some strings to an arduino uno board for PWM control. Never mind the convoluted system here.
Basically the issue I have is that Alexa says cannot apply the SET command to these devices. ON and OFF commands work.
What's weird is that all the other devices in the network, connected only to relays, accept the SET command! Alexa says 'ok' and turns the device on (I use a digitalWrite command).
But for the 'red' 'green' blue' and 'white' devices Alexa asks 'sorry what device?' and then says 'I don't know how to set red to that setting'. However, I can control the brightens with the Alexa app!! But not from a voice command.
What's even more weird, is that once or twice, the SET command has worked for the 'white' device. Then it stopped working.
Any ideas?
Code here
`/*

This is a basic example on how to use Espalexa and its device declaration methods.
*/
#ifdef ARDUINO_ARCH_ESP32
#include <WiFi.h>
#else
#include <ESP8266WiFi.h>
#endif
#include <Espalexa.h>

// prototypes
boolean connectWifi();
//callback functions
void firstLightChanged(uint8_t brightness);
void secondLightChanged(uint8_t brightness);
void thirdLightChanged(uint8_t brightness);
void fourthLightChanged(uint8_t brightness);
// Change this!!
const char* ssid = "SSSuperWiFi";
const char* password = "M1ch3l3p4n3gr0ss1!";
boolean wifiConnected = false;
const int cabinetPin = 12;
const int planterPin = 13;
const int ledPin = 0;
Espalexa espalexa;
EspalexaDevice* device3; //this is optional
void setup()
{
Serial.begin(115200);
// Initialise wifi connection
pinMode(cabinetPin, OUTPUT);
pinMode(planterPin, OUTPUT);
pinMode(ledPin, OUTPUT);
digitalWrite(cabinetPin, LOW);
digitalWrite(planterPin, LOW);
digitalWrite(ledPin, LOW);
wifiConnected = connectWifi();
if(wifiConnected){
// Define your devices here.
espalexa.addDevice("red", firstLightChanged); //simplest definition, default state off
espalexa.addDevice("green", secondLightChanged); //third parameter is beginning state (here fully on)
espalexa.addDevice("blue", thirdLightChanged); //third parameter is beginning state (here fully on)
espalexa.addDevice("white", fourthLightChanged); //third parameter is beginning state (here fully on)

espalexa.begin();

} else
{
while (1) {
Serial.println("Cannot connect to WiFi.


all-packages.nix: add stdenvBootstrapTools to top-level.nix

Description of changes
This allows us to summon ofborg like this:
@ofborg build pkgsCross.aarch64-multiplatform.stdenvBootstrapTools.build
Things done

Built on platform(s)

[ ] x86_64-linux (in progress)
[ ] aarch64-linux (in progress)
[ ] mips64el-linux (in progress)
[ ] powerpc64le-linux (in progress)
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] Fits CONTRIBUTING.md.

@ofborg build pkgsCross.aarch64-multiplatform.bootstrapTools.build

Nits:

Our release.nix calls this stdenvBootstrapTools, so perhaps reuse the same name?
This PR's code won't work on *-darwin.  Maybe that would be confusing, as we actually do have the tools for those platforms as well?  (and e.g. OfBorg does support the platforms)

* Our [release.nix](https://github.com/NixOS/nixpkgs/blob/79d81ff4a8/pkgs/top-level/release.nix#L168) calls this `stdenvBootstrapTools`, so perhaps reuse the same name?

Done.

* This PR's code won't work on *-darwin.  Maybe that would be confusing, as we actually do have the tools for those platforms as well?  (and e.g. OfBorg does support the platforms)

Done.  Thanks for reminding me.  Since ofborg can build the darwin bootstrap-tools this PR should certainly accommodate that.
I looked into generalizing this further, but there really are only three bootstrap-files-builders: linux, darwin, and freebsd... and the freebsd builder doesn't appear to work anymore (I can't get pkgsCross to grok its system-double).
There wasn't an externally-visible way to invoke the "map this hostPlatform to the subdirectory of pkgs/stdenv that builds its boostrap-files" function in pkgs/stdenv/default.nix, and since there are only two working flavors right now I didn't think it was worthwhile to go refactoring pkgs/stdenv/default.nix in order to expose that.

I wouldn't worry about BSD here.  IIRC and on a quick glance, the bootstrap we use for FreeBSD just impurely reuses /usr/bin/* tools: https://github.com/NixOS/nixpkgs/blob/487624c15195/pkgs/stdenv/freebsd/trivial-bootstrap.sh  (and I haven't heard of anyone using NixPkgs on FreeBSD for a long time)

@ofBorg build stdenvBootstrapTools
(I wonder if this picks up attribute sets/maps)

I like this.  I just wonder about aarch64-darwin, as currently we're cross-compiling the bootstrap tools (as you can see in release.nix), but this attribute builds them natively.
This difference might be confusing.  Still, maybe we'd better switch to the native approach here as well (soon-ish), in which case I think we could leave this PR simple as-is, and the difference would disappear.  But darwin is not my topic; I guess /cc @NixOS/darwin-maintainers?

Ugh, yeah, I don't think that expression should be setting the system attribute... it leaves you with no way of saying "I want a native compile".  Or of using those expressions on any other buildPlatform than the one that is hardcoded in the system attribute.
But I think that's a concern to be left for a separate PR.

This looks like a good idea. A next step could be making it possible to get a stdenv with a bootstrap-tools build.

This looks like a good idea. A next step could be making it possible to get a stdenv with a bootstrap-tools build.

Yes, one of my longer-term goals is to have an automated Hydra job ensuring that generating fresh bootstrap-files tarballs wouldn't break anything.  I worry about bitrot there, like one day we wake up and realize that we can't rebuild the bootstrap-files tarballs without breaking stuff.
Actually regenerating the tarballs periodically (each nixos release?) probably isn't a good idea though.  Since each regenerated tarball's provenance includes the previous generation this just creates a really really really long dependency chain for reproducibility, and you've still got a "magic tarball hash" at the start of that chain.  So making sure we can regenerate the bootstrap-tarballs is a good idea, but actually doing that (unless we're forced to) probably isn't.

We had .test in these stdenvBootstrapTools, running on Hydra: https://hydra.nixos.org/eval/1757655?filter=stdenvboot  (maybe I missed your point)

We had .test in these stdenvBootstrapTools, running on Hydra: https://hydra.nixos.org/eval/1757655?filter=stdenvboot (maybe I missed your point)

Almost.
It looks like test-bootstrap-tools rebuilds the bootstrap tools, unpacks them, and uses them to (a) run gcc on a one-liner "hello world", and (b) check that foo --version doesn't crash for foo in {sed, find, diff, patch, make, awk, grep, gcc}.  That's good, it'll let us know if the bootstrap-files become totally broken at some point.
I'm proposing to go further, by replacing or augmenting (a) and (b) with "rebuild all of stdenv".
After spending the last two weeks digging around in the stdenv-bootstrap process I'm a little bit worried about the stdenv-bootstrap process making subtle undocumented assumptions about the bootstrap-files.  We might not be able to document all these assumptions, but we can at least use automated testing to alert ourselves immediately at whatever commit they end up being violated.

Rebuilding the stdenvs is relatively expensive, but I expect it wouldn't happen often, except on changes that already rebuild very many packages anyway.

Ah, I see. Rebuilding the stdenvs is relatively expensive, but I expect it wouldn't happen often, except on changes that already rebuild very many packages anyway.

It could be done only after merges from staging to master.
Anything that causes stdenv to rebuild ought to go through staging anyways.

Additional commit 3ecf7ee fixes an embarrassing oversight.
The force-push following this commit will collapse the PR to a single commit (no other changes).

OMG, this caused removal of the jobs on Hydra and noone's noticed for months: https://hydra.nixos.org/eval/1758946#tabs-removed

Could it be due to job name clash between release.nix / all-packages.nix?
$ git grep -F 'stdenvBootstrapTools =' | cat
pkgs/top-level/all-packages.nix:  stdenvBootstrapTools = if stdenv.hostPlatform.isDarwin then
pkgs/top-level/release.nix:      stdenvBootstrapTools = with lib;

OMG, this somehow caused removal of the jobs on Hydra and noone's noticed for months?

Doesn't Hydra email the meta.maintainers of the removed packages when that happens?

OMG, this somehow caused removal of the jobs on Hydra and noone's noticed for months?

Doesn't Hydra email the meta.maintainers of the removed packages when that happens?

Hydra hasn't emailed in years, AFAIK.

OMG, this somehow caused removal of the jobs on Hydra and noone's noticed for months?

Doesn't Hydra email the meta.maintainers of the removed packages when that happens?

Hydra hasn't emailed in years, AFAIK.

Oh my.  Why not?  Being notified of build failures seems like such a useful feature.
Also is there any way to mass-download the underlying data which are used to render https://hydra.nixos.org/project/nixpkgs?  I would really like to be able to query these data from a shell prompt and with lower latency.

Let's rename the attribute to make job names distinct on hydra: https://github.com/NixOS/nixpkgs/pull/182058


Firefox h264 decoding not functional

Describe the bug
Using this bluebuild template, layered firefox is unable to decode h264 video. When using webRTC video chat it reports that a plugin is missing. When looking at firefox extensions, the following is displayed:

The recommended solution to this problem does not work as it relies on mozilla-openh264, which is not available in negativo17.
What did you expect to happen?
Generally nvidia/hardware decoding works on bluefin-aurora.
Output of bootc status
❯ sudo bootc status
Current staged image: ghcr.io/bahaynes/aurora-nvidia-custom:latest
    Image version: latest-41.20241124.5 (2024-11-25 06:41:43.352466401 UTC)
    Image digest: sha256:6c271be59ca0bb08d4ea6a4ae1c9321c1aa5bf1f83b8880125920b446f2dd92d
Current booted image: ghcr.io/bahaynes/aurora-nvidia-custom:latest
    Image version: latest-41.20241120 (2024-11-20 06:43:13.821154493 UTC)
    Image digest: sha256:cd298e048475ae37eafc52c168d48c3ea7deb5e7d0661e20fa10c8dee34b325b
Current rollback image: ghcr.io/bahaynes/aurora-nvidia-custom:latest
    Image version: latest-41.20241119.1 (2024-11-19 15:52:36.235599092 UTC)
    Image digest: sha256:d36886f8fbed1ba4af264d3c54718ca65e71e3b560323d0cce077c51a089f120

Output of groups
❯ groups
bah wheel docker incus-admin lxd libvirt

Extra information or context
I'm using a rmp-ostree module Firefox because smart card support for Flatpak Firefox is broken.

can confirm this. vp9 and av1 decoding works but not avc1/h264. not sure of the codecs used by instagram either but that too is not hw decoded.

you should enable /etc/yum.repos.d/fedora-cisco-openh264.repo (included by default) and layer mozilla-openh264, this should not be a problem using flatpak (I think?)


JNI Exceptions when using overloaded dot method (perhaps Android specific)

I am getting JNI excepions without much to go on when I use the general purpose dot method on Android. Interestingly even if I only depend on the kotlin Implementation, which I presumed from documentation was entirely in Kotlin.
The only way I've found to fix the issue is directly using the specific Methods, from the Kotlin implementation that is org.jetbrains.kotlinx.multik.kotlin.linalg.KELinAlgEx.dotVV etc).
Perhaps I'll get around to testing more when that happens, but I'm rather busy already so I'm not hopeful.

Please show stacktrace
And what dependencies do you use?

if you depend on multik-default, then there is multik-openblas there (link1, link2).
and what processor do you have in your phone?  if you run in an emulator, it will not work for the reason that the native part is not suitable for emulation. Emulator usually requires android-x64, but we don't have it.
For pure kotlin use implementation("org.jetbrains.kotlinx:multik-kotlin:$multik_version")

with this code:
    val whatever = mk.ndarray(floatArrayOf(1f, 2f, 3f)) dot  mk.ndarray(floatArrayOf(1f, 2f, 3f))

and these dependencies that may be relevant:

    implementation "org.jetbrains.kotlinx:multik-core:$multik_version"
//    TODO replace with default as soon as that wont cause the app to crash because of
//   org.jetbrains.kotlinx.multik.default.linalg.DefaultLinAlgEx.dotVV
    implementation "org.jetbrains.kotlinx:multik-kotlin:$multik_version"

    implementation "androidx.core:core-ktx:$core_ktx_version"

I'm getting on a Samsung Galaxy S10e
2022-08-12 12:42:49.192 26359-16738/com.example.mcgprototype A/le.mcgprototyp: java_vm_ext.cc:578] JNI DETECTED ERROR IN APPLICATION: JNI CallVoidMethodV called with pending exception java.lang.ExceptionInInitializerError:
    java_vm_ext.cc:578]   at org.jetbrains.kotlinx.multik.api.linalg.LinAlg org.jetbrains.kotlinx.multik.api.Multik.getLinalg() (Multik.kt:49)
    java_vm_ext.cc:578]   at java.lang.Number org.jetbrains.kotlinx.multik.api.linalg._linalgKt.dotDefVVNumber(org.jetbrains.kotlinx.multik.ndarray.data.MultiArray, org.jetbrains.kotlinx.multik.ndarray.data.MultiArray) (_linalg.kt:53)
    java_vm_ext.cc:578]   at float[] <USERCODE>(java.util.List, java.lang.String) (<USERCODE>)

oops, sorry, the ACTUAL versions:
        core_ktx_version = "1.8.0"
        multik_version = "0.2.0"

It looks exactly the same if  I use the default impl. As the comment in the dependency somewhat cryptically noted, in that case it crashes even if I use dotVV method directly.

Not as far as I'm aware.
It is based on the generated Android Kotlin template from Android Studio. Unless they do something weird under the hood it should just be JVM.

it also uses amongst others tensorflow, but that shouldnt be relevant, its JNI calls are constantly happening, and as I said, if I "directly" use dotVV and dotMM from the Kotlin-Impl it works fine.

I was unable to reproduce this error.
But I found out a few things:

This error is not related to native code in multik. So if you have multik-kotlin in your dependencies, you should see something like this in project-structure -> dependencies.

This error seems to be related to the Service Provider Interface. This explains why when you call the method directly with dotVV you don't get the exception - you don't use the SPI logic.

Unfortunately, I can't find the cause of the problem without a reproducible case.
Have you tried deleting the app from your phone and rebuilding the project?

Sorry, for the inactivity, I was quite busy with other stuff.
Yes, I see these, and only these multik dependencies.
And after uninstalling the applikation and installing it anew the problem persists.
I'm uncertain what I'm supposed to do to make it reproducible.
Do you think it depends on the device or something else? I could try and build a new Applikation from the kotlin template and just import multik and try to get the issue, but you would be able to do that too, so unless its something device specific or you want that for some sanity check or similar I dont see how that helps.

Do you think it depends on the device or something else?

Not sure.
I'm for reproduction and tried to create a new project from a template, but it worked for me. I have java 11, kotlin 1.7.10
Have you tried running it in an emulator?


Generator output from Windows

See #50

Danke schön for helping me Julian!! :+1:

You're welcome man :)


vNEXT Teleportation Feature Port

Overview
Feature port of teleportation in the MRTK.
Teleportation builds off of Controller Pointers and is configured and utilized in the exact same way.
TODO

[ ] Test on Open VR Platform
[x] Test on WMR Platform
[x] All the events for teleportation are setup but the handlers need to be completed.

Known Issues

[x] After teleportation pointers are now being calculated incorrectly.

Liking what I'm seeing so far, however the Standard Asset stuff should be pulled out separately to avoid dirtying this pr

It's getting there, bit still a ways to go.
The standard asset changes could be pulled out. Mostly I just added better distinctions between different gray values.

Okay, this PR is ready for review.
Haven't been able to test with Open VR because it seems we need to double check how we're mapping the buttons to actions.  Setting the actions doesn't seem to do anything for our inputs. (Might have to address in a separate PR just for OpenVR refactor.)

Haven't been able to test with Open VR

We can cover that.

Haven't been able to test with Open VR

We can cover that.

I'm setup to test with Open VR, but the issues with the implementation needs to be addressed before we can properly test.


Spiel template is missing now

In the current Template folder, the Spiel.tex template is missing. It is not in the JobMarket Repo, either.

Tao solved this issue by uploading Spiel.tex.


Add ability to use a checkstyle-like suppressions file

Add ability to use a checkstyle-like suppressions file to allow for more fine-grained control over when to run rules.
Use case: adding new rules to large repo. We want to ratchet the coverage by requiring all new projects to follow the rules, but we don't require cleanup for old projects right away.
The suppressions files look like this
<suppressions>
  <suppress files="regex1" checks="regex2"/>
</suppressions>

New help output:
$ java -cp /Users/mbileschi/workspace/videoscalastyle/target/scala-2.10/scalastyle-assembly-0.8.0-SNAPSHOT.jar org.scalastyle.Main --help
scalastyle 0.8.0-SNAPSHOT
Usage: scalastyle [options] <source directory>
 -c, --config FILE               configuration file (required)
 -v, --verbose true|false        verbose output
 -q, --quiet true|false          be quiet
     --xmlOutput FILE            write checkstyle format output to this file
     --xmlEncoding STRING        encoding to use for the xml file
     --inputEncoding STRING      encoding for the source files
 -w, --warnings true|false       fail if there are warnings
 -e, --externalJar FILE          jar containing custom rules
 -x, --excludedFiles STRING      regular expressions to exclude file paths (delimited by semicolons).
                                 Cannot be used in conjunction with suppressions files.
 -s, --suppressionsFile STRING   path to checkstyle-like suppressions xml file. For example, the
                                 following config would exclude scalastyle checks with class names
                                 containing regex2 from being run on files containing regex1. More than
                                 one suppress tag is allowed.
                                   <suppressions>
                                     <suppress files="regex1" checks="regex2"/>
                                   </suppressions>

It looks like a large change, but that's mostly because I renamed CheckerTest to CheckerTestHelper so I could add a file that tested the file Checker.scala, and this accounts for about 200 lines of the diff.

I will rebase before merging, but I'd like to keep the history through the review process.

This is an interesting change, and I'd like to discuss it more, but I can't accept a pull request of this size and complexity. Can we do this without the name change? You can always move the necessary function to an Suppression object and the have a SuppressionTest or something like that.

@matthewfarwell sure! I've opened https://github.com/scalastyle/scalastyle/pull/171 which does the name change, and adds the test CheckerTest (the reason for the name change in the first place). In the meantime, I've opened https://github.com/mlbileschi/scalastyle/pull/1 so you can see the diff minus the name change.
Thanks!

Closed due to lack of activity. If you still want this, can you reopen a new PR based on the latest master. Thanks.

This feature seems very useful because I need to exclude some files.
BTW, Is there other way to exclude files in  Scala stylecheck ?


Managed Environment stuck on delete process

Please provide us with the following information:

This issue is a: (mark with an x)

[X] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
Unable to delete Managed Environment after trying for hours.

Steps to reproduce
I can't, it happens randomly.
Expected behavior
Delete and it should work.
Actual behavior
Managed environment is not being deleted.

Closing as it is reported that this has been fixed and in my tests it seems ok too.

The UI isn't functioning as anticipated, especially when compared to other resources. It moves the resources to a "ScheduledForDelete" state, but then the delete bar vanishes and nothing progresses. The CLI does work, but it operates at a significantly reduced speed, taking an unusually long time to complete—somewhere between 5 to 10 minutes.

Seems to happen again

Using cli seems to work alas its really slow

cli sys: "Containerapp environment successfully deleted" put it is still there in portal. Even after 3h.
Is there any trick you know how to --force delete it?


StructureMap integration documentation does not compile

According to the documentation there is a recommended way to use StructureMap with MassTransit
http://masstransit-project.com/MassTransit/usage/containers/structuremap.html
The code example however does not compile. First the cfg lambda parameter is used twice, which is easily reasolved ofcourse, but secondly the call ec.ConfigureConsumers(context); gets the context as parameter, but it expects a parameter of type IContainer...
For now I've reverted my code to using the obsolete LoadFrom() method which prompts me with the warning "LoadFrom is not recommended, review the documentation and use the Consumer methods for your container instead"

Thanks for looking in to this, one thing I noticed in the changed code is that there's a lot of 'getting an IRegistration from the DI container'. But during my fooling around with less than optimal documentation I tried getting an IRegistration from the DI container but got an error that it wasn't registered.
Do we need to manually add a registration for IRegistration or have I missed something? The documentation in the link above doesn't perform any such registration, so I'm unsure how context.GetInstance<IRegistration>() would yield a result.

It isn't added until the .AddMassTransit() method completes, and configuration is completed. After that, all the extension methods used to configure the consumers, sagas, and activities that accept the container/context are resolving the registration from the container to configure the endpoints.


Composing relations through many-to-many join

We have a setup where we have a many-to-many relationship via a join table, e.g.
  module Relations
    class Questions < ROM::Relation[:sql]
      dataset :questions
      schema(infer: true) do
        associations do
          has_many :charts, through: :questions_charts
        end
      end
    end
  end

  module Relations
    class QuestionsCharts < ROM::Relation[:sql]
      dataset :questions_charts
      schema(infer: true) do
        associations do
          belongs_to :questions
          belongs_to :charts
        end
      end
    end
  end

I can query this in my questions repository using a combine_children call to pull out all the charts and that works well, e.g.
        questions
          .combine_children(
            many: {
              charts: charts,
            }
          )

However, what I'd like to do is add an order attribute to the chart which is actually a column on the questions_tables join table, not on the chart table, alongside the attributes that come from the chart table itself, e.g.
[{ id: 1, name: 'my chart', order: 1 }, { id: 2, name: 'my other chart', order: 2 }]

...where id and name are attributes of the chart table.
At the moment the associations definition is happily pulling the charts back through that has_many through call, so I'm expecting to have to write a custom view in the questions_charts relation that does the same thing, but also includes the order attribute from the questions_tables table.
However, I can't work out how to construct this view so that the join still works as it currently does automagically with the association setup. Could you please offer some advice on how to achieve that?
Thanks in advance for your help.

In rom-sql 1.0.0 you will be able to extend an association's relation with your own query logic, but for now you can define a custom view. To make it simpler for you, you can re-use association relation:
class Charts < ROM::Relation[:sql]
  schema(infer: true) do
    associations do
      has_many :questions_charts
      has_many :questions, through: :questions_charts
    end
  end

  view(:for_questions, %[list of attributes in resulting relation]) do |questions|
    # not pretty, I know, there will be a nice API for that in 1.0.0
    rel = associations[:questions].call(__registry__)
    rel.order(:questions__that_column_you_want_to_use)
  end
end

Combine will automatically use this view by convention, so it should just work.
It'll be much simpler in 1.0.0 though. I'm releasing first beta in the upcoming days so stay tuned :)

ps. just updated the example to be a bit nicer

Thanks for the help; I probably confused things a little using order as my example attribute, but that is actually a column on the questions_tables join table, so I want to be able to select all the columns from chart as well as the order column from the join table.
I'll see if I can figure that out from your example, but I'm still not 100% sure how to use the join_table as part of the for_combine.

@mrship the association used under the hood joins that table for you automatically, so you can just do select_append(:questions_tables__some_col_1, :questions_tables__some_col_2).
ps. this will be so much nicer in rom-sql 1.0.0 :)

Thanks for the help so far and apologies for the delay in coming back to you but I'm only just coming back around to this.
When I'm looking at the custom view that you wrote above, it appears to be selecting the question attributes, not chart attributes; e.g: if I strip this back to make Charts#for_questions just replicate the existing association (before adding in any other attributes)
      view(:for_questions, %i(id type created_at updated_at snapshot insight)) do |questions|
        q = for_combine(associations[:questions])
          .where(questions__id: questions.pluck(:id))
        require 'pry'; binding.pry
        q
      end

q (above) produces this relation SQL:
 "SELECT `questions`.`id`, `questions`.`topic_id`, `questions`.`title`, `questions`.`short_title`, `questions`.`methodology`, `questions`.`order`, `questions`.`created_at`, `questions`.`updated_at`, `chart_id` FROM `questions` INNER JOIN `questions_charts` ON (`questions_charts`.`question_id` = `questions`.`id`) INNER JOIN `charts` ON (`charts`.`id` = `questions_charts`.`chart_id`) ORDER BY `questions`.`id`"

implemented like that, I then end up with this error:
     ArgumentError:
       Relations::Questions#preload arity is 3 (2 args given)

when calling the combine_children (note I also have to call the view directly as it doesn't work automatically as you implied)
 questions
          .combine_children(
            many: {
              charts: charts.for_questions,
            }
          )

So, sorry the news isn't better but I think I'm missing something fundamental here.

Unfortunately, the view doesn't get called automatically if I combine_children(many: charts) only if I am explicit about it with combine_children(many: questions.for_charts).

@mrship oh right I forgot that it needs keys to passed explicitly, damn :) see docs for #combine where it's explained

Ok, you mean something like, this?
questions.combine(many: { charts: [questions.for_charts, id: :chart_id] })

unfortunately, that gives a similar error but on charts.
    ArgumentError:
       Relations::Charts#preload arity is 3 (2 args given)

Apologies if I'm being dense here; I feel like I'm so close.

I thought you wanted questions.combine(many: { charts: [charts.for_questions, id: question_id])?

I've created a gist - https://gist.github.com/mrship/3f59b5ab6c40e7cacc0a03eba92742d0 - that shows the problem and hopefully makes it a little clearer what is happening.
The ultimate aim is to have a Question with many Charts, and the Charts have their order from the join table.
If you run the gist, you'll get the same arity issue that I reported above.
Thanks again for the extensive help.

That's very helpful. I'll check it out and get back to you soon
Cheers
Piotr
On 13 Jan 2017, 7:59 PM +0100, Andy Shipman<EMAIL_ADDRESS>wrote:

I've created a gist - https://gist.github.com/mrship/3f59b5ab6c40e7cacc0a03eba92742d0 - that shows the problem and hopefully makes it a little clearer what is happening.
The ultimate aim is to have a Question with many Charts, and the Charts have their order from the join table.
If you run the gist, you'll get the same arity issue that I reported above.
Thanks again for the extensive help.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/rom-rb/rom-sql/issues/123#issuecomment-272518667), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAEKtKYsI_P2qBepmyX8AW1vqjXEqgYks5rR8mcgaJpZM4LZ2sT).

@mrship pheeew, there we go: https://gist.github.com/46584d53fb1f6901b3d29381cec1ccd1

Wow! That works a treat. There's no way I'd ever have got to that point without your help though, so (a) thanks and (b) I'm looking forward to seeing how that becomes easier in v1.0.0!
The good news is that this approach is going to get used a lot throughout my current project, and simplify a lot of features, so thanks again for the help.

@mrship cool! I'll let you know once there's a nicer way, in 1.0.0.beta there's already support for defining associations extended with custom views (ie has_many :questions, view: :ordered) and the only missing part is having ability to extend views's schema with attributes from other relations (this order col in your case).

@mrship hey man, I added a couple of features to make this easier for you. Here's an updated gist: https://gist.github.com/solnic/46584d53fb1f6901b3d29381cec1ccd1
This will be available in rom 3.0.0 and rom-sql 1.0.0

That looks really nice. Thanks for following up. I hope to try 1.0.0 when it comes out of beta.


nice  form error on oversize input incorrect

When adding an small class=error  to an oversize input element, the error message does not align with the input field.
http://screencast.com/t/MUsfjM9CSM
This also happen in IE and chrome.
http://screencast.com/t/wNxxz4CCB5Ax (chrome)
http://screencast.com/t/JAHUUbRz (IE)
If you remove the oversize class from the input field the error message aligns correctly.
http://screencast.com/t/xfuhqwaRM (input without oversize)
Regards
Jamal

Take in to consideration oversize small, medium and large input fields.
The error message is too large on medium input-text, and too small on large input-text.

have this issue too...

Fixed in this commit: 39069c3c768776a452b27b4300ff878cc1117cc2


Fix: Update draw helpers to use graphInstance object.

Summary

This PR Updates:

Removes document from all the draw helpers and replaces it with legendSVG i.e. graphInstance.legendSVG.
Fixes minor bug in Gantt actionHelper where shownTargets were not getting updated correctly. Updated here

Closes #13
Deployment Link

https://terra-graphs-deployed-pr-#.herokuapp.com/
Testing

Additional Details

Thank you for contributing to Terra.
@cerner/terra
@cerner/carbon

Are there no new unit tests with this in this change?

@pranav300 issue description says there is something we need to do with UI, but I cannot see any screenshots in the PR description. may I know the reason why? Correct me if I am wrong.

Are there no new unit tests with this in this change?

@sdadn, I don't think any unit tests are required for this change, as this was a bug where we were using the DOM query object document for selection purposes rather than using the graphInstance that it is within. This caused discrepancies when there were multiple graphs on the same page with the same dataset keys.

@pranav300 issue description says there is something we need to do with UI, but I cannot see any screenshots in the PR description. may I know the reason why? Correct me if I am wrong.

We don't have to change anything with UI as this was an internal bug. Where using the DOM object document for draw helpers, caused the issue.


Calculator App

At this point, I just have the layout implemented and no functionality. Creating this PR at the request of @NathanBland in #1.

I think I can get at least partial functionality implemented this evening.

@keawade Could you change the branch to be calculator until the functionality is final?


Domain for sale?

It seems that slumber.in is for sale by a Stewart Mathers. If it's lost, it would probably make sense to update the docs.

4,688 USD! :smiley:


postgres: Don't infinitely keep restarting when DB couldn't start

This just goes on an infinite loop trying to restart when it will never succeed. Should we not crash the whole process?

cf. https://github.com/juspay/services-flake/blob/113f8cbe962720d7d1d76d04700f3d441dada9f6/nix/services/postgres/default.nix#L337

This can be reproduced by simply running two instances of nix run ....
As an aside, perhaps all services-flake service should check for lockfile on its data directory and crash immediately if it was acquired.


[next][Frontend] Fix use of unique pointer to VFS

Update to follow change in LLVM's VFS.

@dexonsmith I think you may have updated this API recently. Does this change look sound to you? And can you tell me if there are more recent VFS changes in LLVM, were are seeing test failures on the next branch that could be related rdar//71497407&71497525&71497629& 71498224.

I don't remember changing pushOverlay; I'm not sure how my changes would have affected this. I'll take a deeper look though.

@dexonsmith I got the impression this was from your clean up of VFS ownership in Apple's LLVM at a22eda548b8e1f9362018dec194af0ca91b35da0.

Right, I see it now. We use auto a lot less in Clang/LLVM (rule is, never use it if type isn't obvious from context) so we didn't hit this kind of problem there... I thought it was a change with pushOverlay, and was scraping git log to see what might have changed with that.
I'll take a look at the other issues and see if I can help.

(And yes, the change looks sound)

And can you tell me if there are more recent VFS changes in LLVM, were are seeing test failures on the next branch that could be related rdar//71497407&71497525&71497629&71498224.

I looked at those, all related to virtual files in Swift's SourceManager; I don't think they could be related to VFS changes. These are the only things that are recent:
$ git log --since October --oneline llvm.org/main -- llvm/include/llvm/Support/VirtualFileSystem.h llvm/lib/Support/VirtualFileSystem.cpp
75cd8d756d6e Support: Add RedirectingFileSystem::create from simple list of redirections
a22eda548b8e VFS: Return new file systems as uniquely owned when possible, almost NFC
e763e032f8bb Support: Change InMemoryFileSystem::addFileNoOwn to take a MemoryBufferRef, NFC

and they should all be benign; potentially causing compilation errors, but very low risk of causing behaviour changes. The older changes don't look interesting either.

It does look like it would be a different change that would have caused these. Thank you for looking into these! @dexonsmith


Update setup.py

Can/should requires limit the version of python to less then 3.10? (I see it says >= 3.6)

Can/should requires limit the version of python to less then 3.10? (I see it says >= 3.6)

Yes, thanks, updated


Handle FlightCore error message in regards to default install path

Respond with link to or contents of https://r2northstar.gitbook.io/r2northstar-wiki/installing-northstar/troubleshooting#cannot-write-log-file-when-using-northstar-on-ea-app

To be clear, this would happen after an image is OCR'd, correct?

Yes


Add fbtrace_id to FacebookError exception info

Facebook needs the fbtrace_id to look into bugs.  Add it to the
FacebookError exception object so that it can be submitted with bug reports
to Facebook.

Great! Thanks @mgalgs!


Another AlignArguments edge case bug

          Stats(
            id = x.toInt,
            a  = calculateA(
              i   = i,
              rr  = rr,
              arr = arr
            ).toLong,
            c  = calculateC(
              c   = c,
              cc  = cc,
              ccc = ccc
            ),
            cr = calculateCR(
              ends        = consoleCombinedStat.ends,
              impressions = imps
            )
          )

gets reformatted to
          Stats(
            id = x.toInt,
            a  = calculateA(
            i   = i,
            rr  = rr,
            arr = arr
          ).toLong,
            c  = calculateC(
              c   = c,
              cc  = cc,
              ccc = ccc
            ),
            cr = calculateCR(
              ends        = consoleCombinedStat.ends,
              impressions = imps
            )
          )

(the bug is in the a = calculateA(..) block)
If the .toLong  is not present, the indentation is correct. Something about adding a method call is interfering with the indentation level.

Should be fixed in #92


Missing CI for sm-raw-window-handle feature

The changes from https://github.com/servo/surfman/pull/250/ fixed code that no longer compiled.

I think this is implemented now.


Warnings on build.

When I build, I see warnings.
the-thoralf-plugin> stack install
...
-Wunused-matches
-Wunticked-promoted-constructors
-Wdodgy-imports
-Wunused-imports
-Wunused-local-binds
...
thoralf-plugin-<IP_ADDRESS>: copy/register
Registering library for thoralf-plugin-<IP_ADDRESS>..
Completed 3 action(s).

I'd happily fix these warnings if you want to assign this issue to me.

It's yours. Thanks! :)

I fix a number of warnings in #5.


Issue #542: Implemented get_majorana_operator

Implemented get_majorana_operator(operator) and relative tests.
Some indent changes are due to linter.

@googlebot I signed it!

@googlebot I consent.

@googlebot I consent

CI failed due to formatting.
In my last commit I used linter to format the code and it might have changed multiple lines that break something in CI. Feedback or comments welcome to solve this.
Best,
Xavi

@xabomon Go ahead and make the changes the CI linter suggests (https://travis-ci.org/github/quantumlib/OpenFermion/jobs/678090635).  You can run this linter by changing directory to the top-level-dir for openfermion and running ./check/pylint


[Bug] mismatch between markers and markers hebrew tables

Describe the bug
select max(accident_timestamp) from markers_hebrew
-- select max(created) from markers
Max Timestamp is different in both cases, see query: https://redash.hasadna.org.il/queries/1167/source

Locally everything works fine, BUT in production this flow  loads CBS data to markers, involved, vehicles table, but hebrew tables do not update (!)
I managed to perform the queries in this function manually (which is the function that for some reason not working in production)
However manually run is a temporary solution.
I suggest either continuing to debug this in production using DB logs OR use SQLAlchemy  and bulk inserts instead of raw sql for these tables.

Blocked by https://github.com/hasadna/anyway/issues/2134

@ziv17 I didn't manage to solve this issue yet, perhaps you'll have an idea, let's discuss today.

Hi @atalyaalon is the bug intermittent? How often does it occur?
Maybe we can add code that will run after the tables creation, and will test whether is occurred. If it did, it will run some tests, and then re-run the creation of the tables?
By tests, I mean whether there is different number of lines between the two tables, or same lines but different values? How many lines has different values? How many columns on such lines are different? What are the different time values, E.g. is it a difference in time representation?
What do you think?

In redash, there are 3,242 lines missing in markers_hebrew (relative to markers). The latest row in markers_hebrew exists in markers.


emoji box collapsing on clicking outside of the component

when we are clicking outside of the post, emoji box is automatically collapsing if it was open.
Issue #319

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f ...
I checked your fork, there also I couldn't see this change unfortunately.

I did it again. Please check.

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f ...
I checked your fork, there also I couldn't see this change unfortunately.

I did it again. Please check.

you pushed it on master actually

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f ...
I checked your fork, there also I couldn't see this change unfortunately.

I did it again. Please check.

you pushed it on master actually

Previously, I pushed on another branch but it was clearly visible to me but not visible to you.
I do not know how to commit changes after creating a pull request. I will look into it.

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f ...
I checked your fork, there also I couldn't see this change unfortunately.

I did it again. Please check.

you pushed it on master actually

You may clear this branch commits, get the actual commit from master, it'd be auto updated in this pr, then, you may clear and update your master branch as well

OK. Please give me some time.

@divyansh2212 can you please take a look at pr #329 and fix this like that? I don't think we need to create a component which is already available. ClickAwayListener from MUI does the job I guess?

Sure, I will fix it.

@narayan954 I committed changes. Thanks for the hints :)

are you sure, you pushed the changes, cause I am unable to see any change?

I committed changes from my side. Changes are there in my forked repository. Do I need to make another pull request?

you shouldn't need to, I think you didn't push the changes properly, use git push -f ...
I checked your fork, there also I couldn't see this change unfortunately.

I did it again. Please check.

you pushed it on master actually

Previously, I pushed on another branch but it was clearly visible to me but not visible to you. I do not know how to commit changes after creating a pull request. I will look into it.

you can commit on the same branch and it'll be updated or you can ammend you commit and force push the changes as I suggested in discord and it should be updated as well


Make StreamedValueStore store shared_ptr to StreamedValue instances

This is scaffolding that must be rewritten, to avoid storing
the ValueType object in every tensor (again).
Note also that with this change StreamedValueStore and
DirectTensorStore have only a few small differences
in behavior, so we probably want to refactor them to
use more common code later.
The unit test change is needed because now this store
uses free-lists also. I'm not sure if we ever hit the
compacting path in the test.
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

@havardpe PTAL

@havardpe PTAL


Contact/Company/Project Customfield page - When try to add custom field value it does not reflect. we have to close and open to see changes

Describe the bug

When we are try to add some values in customfield page it does not saves or shows any value it shows blank so staff may get confuse
If we want to see customfield saved value we have to close view and open

https://www.berrycast.com/conversations/8a1ae38f-7aef-5caf-a7f5-8aea6515e713

https://www.berrycast.com/conversations/8b683c42-9088-5287-9576-720034e8700e


Week 1

Package
Name
Damian Veltkamp
Class
Tech1 B
Repo link
https://github.com/damian1997/Project-Tech
Summary
Added node packages & run scripts, setup basic express server, added nunjucks templating engine, setup basic router, added a gitignore and added basic controllers
Resources used
Did not use any resources apart from previous work I have published in my repositories
Any thoughts?
No difficulties since I have done these things before

Jep, top.


[Launcher] - XAML cleanup

The XAML needs to be cleaned up

@crutkas I think this is resolved when we moved to WPF?

Yeah, this is vague too


Make it so that the error details get bubble up; presently if you hit an error they are lost

We don't include the error details, see: https://github.com/tweag/servant-oauth2/blob/main/src/Servant/OAuth2.hs#L124
I think this could come about as part of re-working the wai-middleware-auth to be more servant-compatible.

the easiest way to proceed here would be to just add our own custom ServantOAuth2Error type, and throw those, with the information we want to provide.


[RFC] Add build and deployment support for ppc64le arch

This commit adds support in Kubevirt for building and deploying VMs for
IBM Power Systems little-endian architecture (ppc64le).
A .bazelrc file was created in order to move common and architecture
dependent options to it, this makes it easier to add new architectures
support in the future, the architecture dependent options are selected at
runtime by checking the output of uname -m and passing it to the --config
option added.
The WORKSPACE file now contains pointers to the ppc64le specific
dependencies in order to properly build kubevirt and a select was added to
the BUILD.bazel files that use them to use the appropriate ones depending
on the architecture in which Kubevirt is build, the default dependencies
for an unmatched architecture is to use the amd64 ones that were already
defined by Kubevirt.
Signed-off-by: Murilo Fossa Vicentini<EMAIL_ADDRESS>
What this PR does / why we need it: This PR adds support to ppc64le architecture and does some modifications on the current upstream infrastructure in order to
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #2144
Special notes for your reviewer:
There are still some pending concerns / feedback that I would like to hear from the community.
1- The patch changes from io_bazel_rules_docker from release 0.12.0 to 0.10.0 for amd64 as well, so there is the need to make sure it didn't break anything when doing that, using the latest release breaks the build in Power, I still need to get a better understanding as to why, I bisected to a commit in rules_docker where things broke, but it is still not clear to me the reason why and how to address it.
2- In order to build successfully there is the need to get to the kubevirt dockerhub a equivalent image of the builder for ppc64le, similar to the one in: https://hub.docker.com/r/murilofv/builder/tags
In my tests I was pointing the Dockerfile (hack/kubevirt-builder/Dockerfile) to the image in my dockerhub.
3- Scalability for adding support for architectures with regards to WORKSPACE and selects added in the BUILD.bazel files. I am not sure if the approach I did is the best one, I am barely familiar with Bazel, so take the approach I did with a grain of salt, but I didn't find a way to do the selections at a workspace level. The way it is now leads to a potential of bloating of the workspace file in case new architectures support are added and will require further modifications in the BUILD.bazel for each architecture. For scalability this ideally this would be done at a workspace level and keeping the build bazel files without any changes, I thought about an approach of having separate workspace for each arch and selecting at runtime and overwritting the one to be used by the bazel build. I am open to suggestions here, I did an approach that worked for me and with the intent to don't break anything for amd64 builds, but as I mentioned it didn't look easily scalable in the future.
4- I am not sure what would be the proper way to disable SMBios in kubevirt for ppc64le, I did a change in the Convert_v1_VirtualMachine_To_api_Domain which seemed a bit hackish and improper, again open to suggestions on how to properly disable SMBios for Power only given it isn't support on the architecture.
5- The Fedora 30 qcow2 image in the WORKSPACE (fedora30_image_ppc64le) is usually replaced by newer builds often, I am checking with the distro on a way to get a historic image build that would be static (like GA image), so that way build system doesn't break with time, once I get a proper image to point to the pointer will need to be updated, for now I pointed to the latest one available at the time.
6- Some docker containers images showing up with wrong architecture (amd64) instead of ppc64le in dockerhub: https://hub.docker.com/u/murilofv
It works on a Power platform without any issues despite the wrong label, I don't know the reason why, any suggestions as to how to debug this? It will be a pain point in order to upload ppc64le images to the kubevirt docker hub.
7- Even though the patch doesn't address the test environment existent in Kubevirt, I assume that for adding proper support for Power the community will need access to Power systems in order to run functional tests, what would be the ideal / minimal requirements for this? It is the kind of discussion that to be honest will likely be a bit outside my hands, but I would like to have this info to bring to the table internally in IBM.
Release note:

Added build and deployment support for ppc64le architecture

Just adding some logs of a successful deployment of VM / VMI in a Power environment with the patch applied:
$ kubectl apply -f ~/vm-cirros.yaml
virtualmachine.kubevirt.io/vm-cirros created

$ _out/cmd/virtctl/virtctl start vm-cirros
VM vm-cirros was scheduled to start

$ kubectl apply -f ~/vmi-ephemeral.yaml
virtualmachineinstance.kubevirt.io/vmi-ephemeral created

$ kubectl apply -f ~/vmi-fedora.yaml
virtualmachineinstance.kubevirt.io/vmi-fedora created

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
virt-launcher-vm-cirros-5jx57       2/2     Running   0          9m26s
virt-launcher-vmi-ephemeral-52tl4   2/2     Running   0          9m15s
virt-launcher-vmi-fedora-fbx4n      2/2     Running   0          33s

$ kubectl get vm
NAME        AGE   RUNNING   VOLUME
vm-cirros   10m   true

$ kubectl get vmi
NAME            AGE     PHASE     IP          NODENAME
vm-cirros       9m49s   Running   <IP_ADDRESS>   powerio-le21
vmi-ephemeral   9m38s   Running   <IP_ADDRESS>   powerio-le21
vmi-fedora      56s     Running   <IP_ADDRESS>   powerio-le21

$ _out/cmd/virtctl/virtctl console vm-cirros
Successfully connected to vm-cirros console. The escape sequence is ^]

login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
vm-cirros login: cirros
Password:
$ uname -a
Linux vm-cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:20 UTC 2016 ppc64le GNU/Linux

$ _out/cmd/virtctl/virtctl console vmi-ephemeral
Successfully connected to vmi-ephemeral console. The escape sequence is ^]

login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
cirros login: cirros
Password:
$ uname -a
Linux cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:20 UTC 2016 ppc64le GNU/Linux

$ _out/cmd/virtctl/virtctl console vmi-fedora
Successfully connected to vmi-fedora console. The escape sequence is ^]

Fedora 29 (Cloud Edition)
Kernel 4.18.5-300.fc29.ppc64le on an ppc64le (hvc0)

vmi-fedora login: fedora
Password:
[fedora@vmi-fedora ~]$ uname -a
Linux vmi-fedora 4.18.5-300.fc29.ppc64le #1 SMP Fri Aug 24 16:55:54 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux

Looking at the travis-ci test, it looks like I broke something.
I tested on a x86_64 environment I have access and I could build images and deploy VM / VMI without any issues, so I assume I broke something in the CI itself by adding the --config flag / .bazelrc file, is this correct?
The following are some logs of the deployment of VM / VMI in a x86_64 enviroment, similar to the one in the previous comment for ppc64le:
$ kubectl apply -f ~/vm-cirros.yaml
virtualmachine.kubevirt.io/vm-cirros created

$ _out/cmd/virtctl/virtctl start vm-cirros
VM vm-cirros was scheduled to start

$ kubectl apply -f ~/vmi-fedora.yaml
virtualmachineinstance.kubevirt.io/vmi-fedora created

$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-vm-cirros-dwfcw    2/2     Running   0          2m18s
virt-launcher-vmi-fedora-54rm6   2/2     Running   0          2m11s

$ kubectl get vm
NAME        AGE     RUNNING   VOLUME
vm-cirros   2m55s   true

$ kubectl get vmi
NAME         AGE     PHASE     IP          NODENAME
vm-cirros    2m26s   Running   <IP_ADDRESS>   lannister
vmi-fedora   2m18s   Running   <IP_ADDRESS>   lannister

$ _out/cmd/virtctl/virtctl console vm-cirros
Successfully connected to vm-cirros console. The escape sequence is ^]

login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
vm-cirros login: cirros
Password:
$ uname -a
Linux vm-cirros 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:13 UTC 2016 x86_64 GNU/Linux

$ _out/cmd/virtctl/virtctl console vmi-fedora
Successfully connected to vmi-fedora console. The escape sequence is ^]

Fedora 29 (Cloud Edition)
Kernel 4.18.16-300.fc29.x86_64 on an x86_64 (ttyS0)

vmi-fedora login: fedora
Password:
[fedora@vmi-fedora ~]$ uname -a
Linux vmi-fedora 4.18.16-300.fc29.x86_64 #1 SMP Sat Oct 20 23:24:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

@murilofv thanks for this hard work. Note that most of us, including me, will be out for the next two weeks. Looking forward to look into this PR. :+1:

/test

/test all

@murilofv thanks for this hard work. Note that most of us, including me, will be out for the next two weeks. Looking forward to look into this PR. 👍

No worries, thank you for the information, I figured that given the holidays this would be the case.
Similarly to what is seen in the Travis-CI build mentioned before, looking at all the tests failures they seem to be due to the following:
 ERROR: Config value x86_64 is not defined in any .rc file
I assume either the file I created is being overwritten, due to seeing this message before the error:
INFO: Reading rc options for 'build' from /root/go/src/kubevirt.io/kubevirt/.bazelrc:   'build' options: --remote_local_fallback --remote_http_cache=http://bazel-cache.kubevirt-prow.svc.cluster.local:8080/kubevirt.io/kubevirt --jobs=4
Which are not options existent in the .bazelrc file introduced in the patch. So there might be a conflict here that needs to be solved, I'll try to get a better understanding of the issue and see if I can come up with a solution.

/retest

I found two locations where the .bazelrc is being modified and tried the approach of instead of overwriting the file, changing the code to only append the options, and at least for the Travis CI build I don't get the error anymore of not finding the x86_64 config option. I haven't been able to trigger the retest to check the test results regarding this as well.
The problem now, is that using the append leaves the file in modified state from a git perspective and the build is seen as dirty:
$ make build-verify

hack/build-verify.sh

Build is not clean:

Client Version: version.Info{GitVersion:"v0.24.0-35+c9877d90e7a6ee-dirty", GitCommit:"c9877d90e7a6ee2ed622d31c58726cc5c4427a20", GitTreeState:"dirty", BuildDate:"2019-12-23T14:03:12Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}

dial tcp <IP_ADDRESS>:8080: connect: connection refused

HEAD detached at FETCH_HEAD

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   .bazelrc

no changes added to commit (use "git add" and/or "git commit -a")

make: *** [build-verify] Error 1

The command "make build-verify" exited with 2.

This likely wasn't a problem before because the .bazelrc file was in the .gitignore list. As part of my patch I am removing it from it, in order to track the added .bazelrc file by the patch. So I still need to see if I can come up with a solution for this behavior regarding the .bazelrc.

Ok, Travis CI build now passed, although I am not sure how hackish the approach I did really is, I moved the generated file to a new untracked file, given it seems to be a necessity due to it being created at runtime by the CI and potentially dirtying the build, and in order to load it I added to the .bazelrc a try-import pointed to this new file (currently labeled ci.bazelrc), so in case it exists the options set will be loaded for the CI. Let me know if there is any concerns regarding this approach or alternatives to it.

Could someone trigger the tests again? I just want to make sure the patch as it is right now isn't breaking anything else.

/retest

/test all

Thank you for triggering the tests @rmohr , I see the following failure in the tests I looked on:
     import email.FeedParser
ModuleNotFoundError: No module named 'email.FeedParser'
----------------
Note: The failure of target @containerregistry//:pusher (with exit code 1) may have been caused by the fact that it is running under Python 3 instead of Python 2. Examine the error to determine if that appears to be the problem. Since this target is built in the host configuration, the only way to change its version is to set --host_force_python=PY2, which affects the entire build.
If this error started occurring in Bazel 0.27 and later, it may be because the Python toolchain now enforces that targets analyzed as PY2 and PY3 run under a Python 2 and Python 3 interpreter, respectively. See https://github.com/bazelbuild/bazel/issues/7899 for more information.

From what I've been looking into it this seems to circle back to the concern I listed as "1" in of downgrading io_bazel_rules_docker from release 0.12.0 to 0.10.0. I can use the --host_force_python=PY2 in order to workaround this as I did on Power in the .bazelrc, but the problem of doing it is that Python 2 is now deprecated. So this seems like the wrong way to go. So I might need to investigate how to properly fix the issues I am having on Power with the more recent release of io_bazel_rules_docker.

/ok-to-test

@murilofv whitelisted the PR for testing now. Sorry should have done that earlier. Reviewing now.

3- Scalability for adding support for architectures with regards to WORKSPACE and selects added in the BUILD.bazel files. I am not sure if the approach I did is the best one, I am barely familiar with Bazel, so take the approach I did with a grain of salt, but I didn't find a way to do the selections at a workspace level. The way it is now leads to a potential of bloating of the workspace file in case new architectures support are added and will require further modifications in the BUILD.bazel for each architecture. For scalability this ideally this would be done at a workspace level and keeping the build bazel files without any changes, I thought about an approach of having separate workspace for each arch and selecting at runtime and overwritting the one to be used by the bazel build. I am open to suggestions here, I did an approach that worked for me and with the intent to don't break anything for amd64 builds, but as I mentioned it didn't look easily scalable in the future.

We just need different dependencies for testing. They are arch-specific and that is fine. I don't mind if the WORKSPACE file is big because of different dependencies. It is in my opinion just reflecting the reality. We may be able in the future to come up with some bazel magic which allows us to make the selects generic and only add new architectures at one place.
We really want to see all dependencies explicitly because that makes things reproducible.
I think that what will be challenging is doing cross-arch builds. We will have to define the toolchains properly, but at least we can learn from kubernetes/kubernetes there.

5- The Fedora 30 qcow2 image in the WORKSPACE (fedora30_image_ppc64le) is usually replaced by newer builds often, I am checking with the distro on a way to get a historic image build that would be static (like GA image), so that way build system doesn't break with time, once I get a proper image to point to the pointer will need to be updated, for now I pointed to the latest one available at the time.

We have a tool which mirrors all dependencies to our gcs bucket and adds the mirrors to the WORKSPACE file. Once we are happy with the PR, I will run it and push the WORKSPACE file to your PR. That will ensure that we only pull in new builds when we want to, and still have the ones we want available. Makes things very robust and reliable.

2- In order to build successfully there is the need to get to the kubevirt dockerhub a equivalent image of the builder for ppc64le, similar to the one in: https://hub.docker.com/r/murilofv/builder/tags
In my tests I was pointing the Dockerfile (hack/kubevirt-builder/Dockerfile) to the image in my dockerhub.

Creating multi-arch images and manifests is currently in general a little bit tricky. I would at first come up with something like just pushing them with specific tags via travis too.

6- Some docker containers images showing up with wrong architecture (amd64) instead of ppc64le in dockerhub: https://hub.docker.com/u/murilofv
It works on a Power platform without any issues despite the wrong label, I don't know the reason why, any suggestions as to how to debug this? It will be a pain point in order to upload ppc64le images to the kubevirt docker hub.

You may have to set the architecture flag on container_pull. I guess that in some cases you use an amd64 base image, but since we copy in static binaries or just isos, it would still run on ppc.

4- I am not sure what would be the proper way to disable SMBios in kubevirt for ppc64le, I did a change in the Convert_v1_VirtualMachine_To_api_Domain which seemed a bit hackish and improper, again open to suggestions on how to properly disable SMBios for Power only given it isn't support on the architecture.

I think we should detect in the validating webhook in virt-api that this can't work and reject entities which set this.

First and foremost thank you for the review @rmohr I'll try to address the changes you requested as soon as possible.

Some minor comments. We need to be able to use newer rules_go, that is the main blocker I see at the moment. Once that is resolved, I think the PR is pretty much ready.

Yeah, I agree, this is the main blocker, the problem I am having right now is that I think rules_docker is not working properly with different architectures when the following patch was added: https://github.com/bazelbuild/rules_docker/commit/f1d9b67f43afe0926b144db81d10dcf9983a0fe9
I tried adding the architecture to the container_pull, but it didn't help, I see it got specified but the end results was the same. With this new release (started at v0.10.1) of rules_docker I start seeing the following problem:
INFO: Call stack for the definition of repository 'fedora_ppc64le' which is a container_pull (rule definition at /root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/external/io_bazel_rules_docker/container/pull.bzl:203:18):
 - /root/go/src/kubevirt.io/kubevirt/WORKSPACE:306:1
ERROR: An error occurred during the fetch of repository 'fedora_ppc64le':
   Pull command failed: /root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/external/go_puller_linux/file/downloaded: /root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/external/go_puller_linux/file/downloaded: cannot execute binary file
 (/root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/external/go_puller_linux/file/downloaded -directory /root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/external/fedora_ppc64le/image -os linux -os-version  -os-features  -architecture ppc64le -variant  -features  -name index.docker.io/library/fedora@sha256:de1e23d807365800621d10efe27fa7eea865ee0bf9f1beca316f919972312695)

So I get this cannot execute binary file to actually pull the the container, which I assume is due to it being a amd64 binary.
I'll attempt to investigate it a bit further to see if it will be something I need to attempt to address in rules_docker or if I can attempt to workaround it somehow in Kubevirt.

Yeah, I agree, this is the main blocker, the problem I am having right now is that I think rules_docker is not working properly with different architectures when the following patch was added: bazelbuild/rules_docker@f1d9b67

Oh wait, rules_docker is probably not as bad as rules_go. Still, did you consider opening an issue so that someone from rules_docker could assist?

Yeah, I agree, this is the main blocker, the problem I am having right now is that I think rules_docker is not working properly with different architectures when the following patch was added: bazelbuild/rules_docker@f1d9b67

Oh wait, rules_docker is probably not as bad as rules_go. Still, did you consider opening an issue so that someone from rules_docker could assist?

Well, I was poking around a bit at the rules_docker github just now and came accross this issue: https://github.com/bazelbuild/rules_docker/issues/1155
It seems like this change to Go implementation is affecting other architectures as well and they don't have enough bandwidth to work on this right now. I'll see if I can do anything to either workaround or address this issue.

@murilofv Nice work, but looks like we can not just downgrade docker, because our CI fails on
Traceback (most recent call last):
  File "/root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/execroot/__main__/bazel-out/k8-fastbuild/bin/push-other-images.runfiles/containerregistry/tools/fast_pusher_.py", line 29, in <module>
    from containerregistry.client import docker_creds
  File "/root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/execroot/__main__/bazel-out/k8-fastbuild/bin/push-other-images.runfiles/containerregistry/client/__init__.py", line 23, in <module>
    from containerregistry.client import docker_creds_
  File "/root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/execroot/__main__/bazel-out/k8-fastbuild/bin/push-other-images.runfiles/containerregistry/client/docker_creds_.py", line 31, in <module>
    import httplib2
  File "/root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/execroot/__main__/bazel-out/k8-fastbuild/bin/push-other-images.runfiles/httplib2/__init__.py", line 28, in <module>
    import email.FeedParser
ModuleNotFoundError: No module named 'email.FeedParser'

Can you also add
matrix:
  include:
  - os: linux
  - os: linux-ppc64le

to .travis.yml? That will at least verify that we can build for ppc properly.

I am not confident enough that it will pass all the verifications the Travis-CI is doing at this point. I didn't touch any of the test infrastructure to make sure they are aligned with some modifications that are specific to Power, like for example making it run in privileged mode. But I can certainly give it a whirl and see what errors show up.
On the note of enabling it in the .travis.yml is this the proper way to enable it? From what I've been looking at the travis CI docs [1], it makes it seem like I just need to add the following:
arch:
  - amd64
  - ppc64le
os: linux

From what I've been reading in a post [2], the linux-ppc64le is a legacy tag that would still work but recommended to switch to arch / os.
[1] - https://docs.travis-ci.com/user/multi-cpu-architectures/#testing-on-multiple-cpu-architectures
[2] - https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture-ibm-power-ibm-z

I am not confident enough that it will pass all the verifications the Travis-CI is doing at this point. I didn't touch any of the test infrastructure to make sure they are aligned with some modifications that are specific to Power, like for example making it run in privileged mode. But I can certainly give it a whirl and see what errors show up.

Building and unit tests should pass. Otherwise we can't guarantee anything at all. Do you agree?

arch:

amd64
ppc64le
os: linux

Sounds good.
I also think that we want for not skipping any deploy steps for PPC (for this PR). Could you add something like
on:
  condition: TRAVIS_CPU_ARCH = amd64

to the deploy steps in .travis.yml?

/retest

@rmohr IMHO it looks good, can you please take another round of review?

Also there was the introduction of jq in commit 881a3cb . It also does not have a ppc64le container, so I ended up rebuilding it and generating a manifest similarly to the builder and I am temporarily pointing to it in the patch. I'll have to check with the community on both jq and base-builder (given it is a dependency for jq) to have containers built for Power.

Ok, I got this sorted out with the communities and now there is a manifest for both ppc64le and amd64, so I pushed an updated patch reverting the pointer from the images I built back to the original jq one from imega.

Looks like the make bazel-test can take longer than the expected timeout in Travis and the ppc64le was terminated due to it:
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

The build has been terminated

I am adding a travis_wait before it to extend the timeout to 20 min and hopefully we don't see this issue again.

@murilofv I created #3045 which should allow us to build the builder image on amd64. Can you try using the resulting multi-arch image kubevirt/builder@sha256:5e0c047e3cac6123419c972bb9d31d89f686751b962190c147379d846f5d1e46 in hack/dockerized?

@murilofv I created #3045 which should allow us to build the builder image on amd64. Can you try using the resulting multi-arch image kubevirt/builder@sha256:5e0c047e3cac6123419c972bb9d31d89f686751b962190c147379d846f5d1e46 in hack/dockerized?

From what I tested in my system it is working, I'll change the patch from the image I built to this new pointer, thank you for the help in getting it built @rmohr .
As for the change I made earlier regarding travis_wait I am not really happy about it, it seems to be hiding the actual tests logs:
https://travis-ci.org/kubevirt/kubevirt/jobs/645561163#L1048
as opposed to what was previously shown: https://travis-ci.org/kubevirt/kubevirt/jobs/641073915#L1183
I need to think if there is a way to address this better

I need to think if there is a way to address this better

I think that I deliberately added common --noshow_progress --noshow_loading_progress in hack/dockerized. Maybe all you need to do is making bazel more verbose again ...

oh and in another project I solved the "nothing printed for 10 minutes issue" with a simple script line in .travis.yml:
$ for i in `seq 1 60`; do sleep 60; echo 'keep alive'; done & # this backgrounds
$ continue work

I need to think if there is a way to address this better

I think that I deliberately added common --noshow_progress --noshow_loading_progress in hack/dockerized. Maybe all you need to do is making bazel more verbose again ...

My concern with doing that is how much the log would grow due to it, to mitigate the increase in the log maybe I should move from common to only build / run and test would remain verbose, I'll modify the patch to see how it goes if I do it this way.

Just printing a keep alive in the background is also fine for me. As far as I remember, bazel was very verbose ...

Looking at the log I don't think I noticed any difference from keeping the test in verbose mode, might need to go down the route of the keep alive route in this case, I'll submit the change soon

https://github.com/kubevirt/kubevirt/pull/3045 is approved. When it is in, we can do a final review round here and approve it too.

/hold cancel
builder  changes are merged now. Two minor change requests which don't require a hold.

Patch with the changes requested by @rmohr regarding pkg/virt-launcher/virtwrap/api/converter_test.go and pkg/virt-launcher/virtwrap/api/schema_test.go by adding full xml for ppc64le instead of if / else to generate it. Let me know if there are any concerns regarding how the change was made Roman.

/retest

/hold
@murilofv the PR description is pretty outdated now I think. Can you go over it too?

/hold cancel

@murilofv I took the liberty to cross out but keep the resolved issues from the PR description. Thanks for this awesome work. :+1:

/retest

@murilofv I took the liberty to cross out but keep the resolved issues from the PR description. Thanks for this awesome work. 👍

Thank you, sorry for the delay, I edited the description as well adding some info on the modifications done in the PR.

@murilofv can you create an issue for the following follow-ups:
* Investigate on how to remove the privileged flag for virt-launcher

Opened issue https://github.com/kubevirt/kubevirt/issues/3066 for it

* Always execute all unit tests for all platforms and don't rely on architecture

Opened issue https://github.com/kubevirt/kubevirt/issues/3067 for it

* Investigate pushing images on releases.

* investigate getting the right container image architecture

These two are kind of related and depend first and foremost on the second one, I opened a issue https://github.com/kubevirt/kubevirt/issues/3065 for it and mentioned in it the idea of the end goal of pushing the images on releases as a manifest list. Let me know if you want me to create a separate issue for it.
Also, let me take the time to thank you guys for all the feedback / help with this PR.


Update workers to connect to faktory when they are started

Updates the worker server to open a connection to faktory when it is started.
Tasks

[x] Open a new connection when starting a new worker
[ ] Send the BEAT command at regular intervals to prevent the connection being closed by faktory

Codecov Report

Merging #26 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #26   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          17     17
  Lines         143    151    +8
=====================================
+ Hits          143    151    +8

Impacted Files
Coverage Δ

lib/faktory_worker/connection_manager.ex
100% <ø> (ø)
:arrow_up:

lib/faktory_worker/worker.ex
100% <100%> (ø)
:arrow_up:

lib/faktory_worker/connection.ex
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9debde9...72ca3d9. Read the comment docs.

Codecov Report

Merging #26 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #26   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          17     18    +1
  Lines         143    168   +25
=====================================
+ Hits          143    168   +25

Impacted Files
Coverage Δ

lib/faktory_worker/worker_supervisor.ex
100% <ø> (ø)
:arrow_up:

lib/faktory_worker/connection_manager.ex
100% <100%> (ø)
:arrow_up:

lib/faktory_worker/worker.ex
100% <100%> (ø)
:arrow_up:

lib/faktory_worker/worker/server.ex
100% <100%> (ø)

lib/faktory_worker/connection.ex
100% <100%> (ø)
:arrow_up:

lib/faktory_worker/protocol.ex
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9debde9...34f2d7d. Read the comment docs.


Removed files related to vpcctl binary

With the latest changes in upstream in which the vpcctl logic has been inlined with the ccm logic so there is no more need of using vpcctl as a seperate binary.

@Karthik-K-N can merge this now or once we merge the latest changes?

@Karthik-K-N can merge this now or once we merge the latest changes?

i think it will be better to merge https://github.com/openshift/cloud-provider-powervs/pull/6 before this\


A fatal error has been detected by the Java Runtime Environment:

Please provide a brief summary of the bug
I am trying to run to get response from serial port.
I have checked all the possible outcomes to fix this issue but I am unable to fix it.
Below is the error im getting again and again.

Please provide steps to reproduce where possible
import gnu.io.CommPortIdentifier;
import gnu.io.CommPort;
import gnu.io.SerialPort;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.Scanner;
public class CommPortExample {
public static void main(String args[])
{
Scanner scanner = new Scanner(System.in);
System.out.println("Enter command: ");
String command = scanner.nextLine();
scanner.close();
String portName = "COM11";
    try{
        CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName);
        if (portIdentifier.isCurrentlyOwned())
        {
            System.out.println("Port is currently in use");
        }
        else {
            CommPort commPort = portIdentifier.open(CommPortExample.class.getName(), 2000);

            if (commPort instanceof SerialPort){
                SerialPort sP =(SerialPort)commPort;
                sP.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);

                InputStream in = sP.getInputStream();
                OutputStream out = sP.getOutputStream();

                out.write(command.getBytes());

                byte[] buffer = new byte[1024];
                int len;

                StringBuilder response = new StringBuilder();
                while ((len=in.read(buffer)) >-1 )
            {
               response.append(new String(buffer, 0,len));
               if (response.toString().contains("Expected response"))
               {
                break;
               }
            }
            System.out.println("System Response: "+response.toString());
            sP.close();

            }

            else
            {
                System.out.println("Error");

            }
        }
    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
}

}
Expected Results
Enter command:
O0265Z
The device connected to usb port will beep after getting this command
Actual Results
Enter command:
O0265Z

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000180005b00, pid=32216, tid=8300

JRE version: OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (<IP_ADDRESS>+1) (build <IP_ADDRESS>+1)
Java VM: OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (<IP_ADDRESS>+1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
Problematic frame:
C  [rxtxSerial.dll+0x5b00]

No core dump will be written. Minidumps are not enabled by default on client versions of Windows

If you would like to submit a bug report, please visit:
https://github.com/adoptium/adoptium-support/issues
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
What Java Version are you using?
1.8.0_381
What is your operating system and platform?
Windows 11 pro version  22H2
Using VS Code x64-1.82.2
How did you install Java?
https://www.java.com/en/download/
DOwnload from here and install it
Did it work before?
No response
Did you test with the latest update version?
No response
Did you test with other Java versions?
No response
Relevant log output
No response

@itoobaykhan That's a crash in the native code in the rxtxSerial.dll library.  You'll need to report this issue to that library.

Oh okay. Thank you. I'll report it.


Overlap between taps panel and tabs when the sidebar is minimized. Sidebery beta V5.

I am using sidebery V5 beta. When the sidebar is minimized the taps panel and tabs overlap.
This are the tabs expanded when the mouse hovers over them:

And this is the look when the sidebar is minimized:

Is there any way to avoid this overlapping? Thanks for your time.

@JacoboGuijar I checked it with the latest Sidebery beta (it's specified in the new file) and was able to modify mostly everything I wanted to. If you are willing to check it out, re-download the userChrome.css file for your OS (version mostly for aesthetic reasons and because I'm on Linux right now).

Closed as I implemented support for Sidebery v5 beta.