Test Ball Bouncing Simulations And Countering it back with Melee for Moss Plant of Guwama

Currently don't mind it. We will discuss it after the testing of the Icarasia AI.

@Pseudo-64 Do we still need this issue open? The Moss Plant was already merged

Yeah closing it now. Not needed anymore.


Temp

code is functioning properly and can be merged to main

not sure why Travis-CI is having issues, runs fine locally and their log in page is denying me access for some reason.  I'll have to migrate to github actions in the near future


Fuzzing Time Duration

Hello, I have questions regarding RTG.
How long is the fuzzing duration performed by RTG and is there any configuration to set how long the fuzzing duration is?

Hello,
currently, RestTestGen does not incorporate a time-based budget feature. The determination of how long to test an API remains within the realm of testing strategies.
Nonetheless, within the NominalAndErrorStrategy, there exists the flexibility to adjust certain parameters. For instance, you can modify the number of attempts for which RestTestGen generates test interactions for a specific operation. This adjustment can either extend or curtail the overall testing time.
The relevant parameter can be found on line 36 within the NominalAndErrorStrategy class. Currently set at 20, this value holds potential for adjustment—perhaps to 100 or even 500, as an illustration.
In instances where your API poses considerable challenges for automated testing, we recommend a slight increment in the parameter on line 24 of the GraphBasedOperationsSorter class (maximumAttempts), from 10 to 15-20. This particular parameter dictates the number of attempts undertaken to test an operation that hasn't yielded a successful status code before giving up on its testing.
Feel free to inform me if I can be of help with regards to the other testing strategies provided by RestTestGen.

Hello,
currently, RestTestGen does not incorporate a time-based budget feature. The determination of how long to test an API remains within the realm of testing strategies.
Nonetheless, within the NominalAndErrorStrategy, there exists the flexibility to adjust certain parameters. For instance, you can modify the number of attempts for which RestTestGen generates test interactions for a specific operation. This adjustment can either extend or curtail the overall testing time.
The relevant parameter can be found on line 36 within the NominalAndErrorStrategy class. Currently set at 20, this value holds potential for adjustment—perhaps to 100 or even 500, as an illustration.
In instances where your API poses considerable challenges for automated testing, we recommend a slight increment in the parameter on line 24 of the GraphBasedOperationsSorter class (maximumAttempts), from 10 to 15-20. This particular parameter dictates the number of attempts undertaken to test an operation that hasn't yielded a successful status code before giving up on its testing.
Feel free to inform me if I can be of help with regards to the other testing strategies provided by RestTestGen.

Thanks for the suggestion, I will try the parameter adjustments so they can extend the fuzzing duration.
I have another question. Some of my endpoints require complex request body such as nested object and list of object. When I run rtg, I got ParameterCreationException and rtg generated empty request body {} for those endpoints. Is there any workaround or configuration to fix this exception?
For note, rtg generated correct request body for endpoints that do not require complex request body (simple object).

Hey there,
I will proceed by closing this issue as this is only related to fuzzing time.
Could you do me a favor? If you're experiencing the ParameterCreationException issue, could you open a new issue and explain what's been going on? Honestly, I haven't come across that exception before. It would be super helpful if you could also share the RestTestGen log and the OpenAPI specification file that's causing the problem.
Thanks a bunch for your patience and time.
Take care,
Davide


Add Support for Horizontal Rule in Markdown

Description:

I want to introduce support for horizontal rules in our Markdown rendering. When users add --- in their Markdown, it should be converted to an
 tag in the HTML output.

Steps to Implement:

Implement the functionality to convert --- in Markdown to an
 tag in the rendered HTML.

close by fb0a837


feat: initial project structure and implementation

This PR includes the initial project structure and the implemented files for the CrateGen project. This is the initial version of the project and it is not yet complete. Please review the structure and provide any feedback or suggestions for improvement.
The project structure includes:

Abstract converter class
TES and WES converters
Coordinating manager class
CLI integration
Unit and integration tests
Updated pyproject.toml for proper dependency management.

Thank you!

hey @Karanjot786, your CI build is failing. It seems you need to update your poetry.lock file. Just add the "poetry lock" command after installing poetry and you should be good. Also I think you should consider using the actions/setup-poetry action to install poetry as that provides a more stable experience, and its actually built specifically for such a situation, as opposed to script you're currently using.

Hi @SalihuDickson,
Thank you for your feedback. I have resolved the CI pipeline failing issue in this PR by updating the pyproject.toml file.
I apologize for the PR doing more than intended for an initial setup. My initial thought was to get the basic structure and some key functionality in place to provide a clearer picture of the overall design. However, I understand the importance of breaking it down into more manageable pieces.
Regarding the converters, I wanted to provide a working example to show the intended direction, but I agree it may have been premature without fully setting up the WES and TES models first. I'll refocus on setting up the models properly in the next steps.
Thank you again for your guidance.

thank you @Karanjot786, you should go ahead and push you CI fix so get rid of the error.
Next you should make sure all your CI checks are passing (your tests are failing aswell). When those are up and running we can move into any potential issues in the actual code. Great work!

Hi @SalihuDickson,
Thank you for your feedback. I have resolved the CI pipeline issue and pushed the fix to remove the error. I'll now focus on ensuring all CI checks are passing and address the failing tests.
Thanks again for your guidance.

Hi @SalihuDickson and @uniqueg,
I'm sorry for the comment mess earlier. I've now resolved all the issues, and I'm happy to report that all the checks are successful.
Thank you for your patience and guidance.

Hey @Karanjot786, just a few things;

I noticed that you commented out the test job in the CI workflow, however you haven't resolved the issue that was making the test fail. I don't believe this is the ideal way to deal with this issue, testing is an important part of any CI workflow and it makes our jobs much easier as reviewers.
Can you add some detailed instructions on how to run the package including how the input might need to be formatted, i keep running into errors on each turn and Its making the review process more tedious as i have to figure out for myself the next step.

Hi @SalihuDickson ,
Thank you for your feedback.
I apologize for commenting on the test job in the CI workflow. I focused on resolving the major issues causing the CI workflow to fail. I've re-enabled the test jobs, but I've commented out two tests that still need further attention and resolution in the future.
I've added detailed instructions on how to run the package, including the required input formats. This should help streamline the review process.
I will include some dummy data to facilitate testing without needing additional data. I'll also set the required properties on the input to false and set a default for the output file.
I'll make these updates as soon as possible and let me know if I need any more help.

Description
This PR includes fixes for the integration test and provides detailed instructions on how to run the CrateGen package.
How to Run the Package
Prerequisites

Python 3.11 or higher
Poetry for dependency management

Installation

Clone the Repository:
git clone https://github.com/elixir-cloud-aai/CrateGen.git
cd CrateGen

Install Dependencies:
poetry install

Running the Package
You can use the CLI tool provided by CrateGen to convert TES or WES data to WRROC format.
TES to WRROC Conversion

Prepare input data:

Create a JSON file with TES data, e.g., tests/data/input/tes_example.json.

Run the Conversion:
poetry run python -m crategen.cli --input tests/data/input/tes_example.json --output tests/data/output/tes_to_wrroc_output.json --conversion-type tes_to_wrroc

Run the Conversion:
poetry run python -m crategen.cli --input tests/data/input/wes_example.json --output tests/data/output/wes_to_wrroc_output.json --conversion-type wes_to_wrroc

Running Tests
To ensure everything is working correctly, you can run the tests:
poetry run pytest --cov=crategen tests

hey @Karanjot786, thank you for getting to these so quickly, however there are still a few issues that need resolving;

In your instructions you set an option for --conversion-type, it should be --type. You also set the values as tes_to_wrroc and  wes_to_wrroc when it should be tes-to-wrroc and wes-to-wrroc, according to the available values for this option in your application.
The example you provide for the input field is json, however your the application does no conversion from json to python dicts so you can work with the data, which breaks the application.
The convert_to_iso8601 method in the both converters is not working as expected, at least not for the time format provided by the docs on the ga4gh TES API or the ga4gh WES API.
Also if they both work the same way perhaps you don't need separate methods, you can just create one utility function that does works for both scenarios.
The wes to wrroc converter sets an array for outputs when it should be an object, accroding to the ga4gh WES schema.

For future reference these really aren't issues that should be caught by a reviewer, they are fairly basic and can be uncovered by some basic testing before making an MR.
Some points I would like you to consider to improve the interaction btw the user and the CLI;

A user should be able to run the program without adding any options and then follow step by step prompts to fill out the required  options instead of throwing an error for any missing options
If a user does not enter the option for type, the options for type should be list where they can select what they want.

I apologise that this PR is taking time to be approved but the fact that it does so much means there is a lot of functionality to go through and test before moving forward, in the future we can mitigate this by making sure each PR tackles 1 specific issue directly for just 1 conversion (when a conversion is concerned), that way when the functionality has been pinned down you can easily apply it to other conversions.

Hi [Mentor's Name],
Thank you for the detailed feedback and your patience. Here are the steps I will take to address the issues:
Update the Instructions:

Correct the --conversion-type option to --type and the values to tes-to-wrroc and wes-to-

Input Data Conversion:

Add functionality to convert JSON input data to Python dictionaries within the

ISO 8601 Conversion:

Revise the convert_to_iso8601 method to properly handle the time format from the GA4GH TES and WES APIs.
Create a shared utility function for time conversion to be used in both

WES to WRROC Converter:

Correct the outputs field to be an object instead of an

User Interaction Improvements:

Implement step-by-step prompts for users to input required options if they are missing.
Provide a list of options for the --type argument if it is not provided by the user.

I will make these changes and thoroughly test the application before updating the PR. Thank you for your guidance and support in ensuring the quality of this project.

Hi @SalihuDickson,
Updated CLI Implementation:

Changed the --conversion-type option to --type.
Implemented step-by-step prompts for missing options.
Provided a list of options for the --type argument if not provided.

TES Converter:

Fixed the convert_to_iso8601 method to properly handle the time format from the GA4GH TES API.
Utilized a shared utility function for time conversion.
Ensured the input JSON data is converted to Python dictionaries.

WES Converter:

Fixed the convert_to_iso8601 method to properly handle the time format from the GA4GH WES API.
Utilized a shared utility function for time conversion.
Corrected the outputs field to be an object instead of an array.
Ensured the input JSON data is converted to Python dictionaries.

Utility Function:

Created a shared utility function for ISO 8601 time conversion in crategen/utils/formatting.py.

How to Run the Package
Install Dependencies:
Ensure that all dependencies are installed using Poetry.
poetry install

Create Sample Input Data
Prepare sample JSON files for both TES and WES to be used as input for the CLI.
Sample TES Input (tes_example.json):
{
    "id": "task-id",
    "name": "test-task",
    "description": "test-description",
    "executors": [{"image": "executor-image"}],
    "inputs": [{"url": "input-url", "path": "input-path"}],
    "outputs": [{"url": "output-url", "path": "output-path"}],
    "creation_time": "2023-07-10T14:30:00Z",
    "end_time": "2023-07-10T15:30:00Z"
}

Sample WES Input (wes_example.json):
{
    "run_id": "run-id",
    "run_log": {
        "name": "test-run",
        "start_time": "2023-07-10T14:30:00Z",
        "end_time": "2023-07-10T15:30:00Z"
    },
    "state": "COMPLETED",
    "outputs": [{"location": "output-location", "name": "output-name"}]
}

Run the TES to WRROC Conversion
Use the CLI to convert the TES input data to WRROC format.
poetry run python -m crategen.cli --input tests/data/input/tes_example.json --output tests/data/output/tes_to_wrroc_output.json --conversion-type tes-to-wrroc

Verify the output in tes_to_wrroc_output.json.
Run the WES to WRROC Conversion
Use the CLI to convert the WES input data to WRROC format.
poetry run python -m crategen.cli --input tests/data/input/wes_example.json --output tests/data/output/wes_to_wrroc_output.json --conversion-type wes-to-wrroc

Verify the output in wes_to_wrroc_output.json.
Additional Notes

Update unit tests for both TES and WES
Refactored code to improve maintainability and readability.

Hi @SalihuDickson ,
Thank you for the feedback and guidance.

I've confirmed that the TES schema has the end_time key in the logs, not directly in the task. I've updated the code to reflect this.
I've consolidated the utility functions into a single utils.py file as suggested.
I've moved the tests to a separate branch and created a new PR for them.

Please review the updated PR and the new PR for the tests.

Hi @uniqueg
Thank you for the feedback. I agree that it's important to clearly define the library and CLI's functionality in more detail. I will address the highlighted issues and ensure we have a well-defined plan moving forward.
I will implement separate functions in the CLI for packaging (crategen package) and extracting (crategen extract) WRROCs. Additionally, I will create two abstract classes: a WRROC packager and a GA4GH Cloud API request extractor, to handle these functionalities separately.
I will ensure the tool can handle multiple hierarchical WRROC profiles and produce the highest level WRROC possible based on the available information. I'll also consider how to incorporate additional data from TRS/DRS.
I will add validation for both input and output data. Additionally, I will work on implementing auto-detection of WES/TES data to select the appropriate packager class without user input.
I will design a user interface and flow that allows users to select the specific WRROC entity to be processed, with sensible defaults for processing all available WRROC entities when applicable.


fix: UIWebView optimize argument

This is also wrong in the release notes: https://docs.microsoft.com/en-us/xamarin/ios/release-notes/13/13.16
Reference: https://github.com/xamarin/xamarin-macios/pull/8009

@campersau : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Embeddings using Huggingface InferenceClient

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
Is there any support for using the InferenceClient for a hosted embedding model. I did look into the HuggingfaceInferenceAPIEmbeddings but seems like I have to specify a model_name there.
This is how I generate embeddings currently with my InferenceClient
from huggingface_hub import InferenceClient

client = InferenceClient("<hosted_embedding_url>")

embeddings = client.feature_extraction("Testing")

@ss2342 looking at the source code for the class, and for the InferenceClient, I think "model" in this case can also be the URL (The InferenceClient doesn't list a URL option in its args, but the model is the first kwarg, so in your example you are passing in the URL as the model)
Can you give that a shot?


Error 'Key is missing or incorrect.' for a confirmed working api/key combo

Describe the bug
Plugin configured per instructions:

    {
       "name": "StarProjector",
       "debug": true,
       "projectors": [
           {
               "name": "GalaxyProjector_Tuya",
               "tuyaId": "aaaaaaaaaaaaaaa",
               "tuyaKey": "kkkkkkkkkkkkkkkkkkk"
           }
       ],
       "platform": "StarProjector"
   },

The api id and key used are working fine for the HomeAssistant Tuya v2 integration.  I have also tried my email address for the value of tuyaID with the api key but getting the same error.
I've checked through the api authorisation steps you've linked here on github and it's identical for the homeassistant integration.  I am using an approved 'Individual Developer' API account w/ country/region of United Kingdom.
All related lines from HomeBridge log:
[8/27/2021, 2:49:42 PM] [StarProjector] Initializing StarProjector platform...
[8/27/2021, 2:49:42 PM] [StarProjector] GalaxyProjector_Tuya: An error occured during setting up the device!
[8/27/2021, 2:49:42 PM] [StarProjector] Key is missing or incorrect.
Additional context
Debugging is enabled and was hoping I could work this one out myself.  Is there any way for me to get more info on this error?
### Update: Looked at your code.  Seems it's failing in the tuyapi part before your plugin really starts.  Would this be better logged over there?

Did you run the npm i @tuyapi/cli -g  command like described on the page?
Did you , after that, run the "tuya-cli wizard"  command and used the device ID from the iot tuya device id in this wizard?
Then it will generate a device and key id for the projector.
YOu need to enter those into homebridge, not the credentials from the tuya website.

Ah - missed that step, many thanks for highlighting.  All sorted now :)


Unable to start instances with DATA volumes of deploy-as-is template having instance snapshots

ISSUE TYPE

Bug Report

COMPONENT NAME

Template, VMware

CLOUDSTACK VERSION

4.19

OS / ENVIRONMENT

Instance deployed from deplo-as-is template. VMware vSphere 8.0
SUMMARY

While starting an instance created from deploy-as-is template cloudstack tries to tear down the data disks. Since the instance has data volumes attached before the instance snapshot vCenter declines the teardown. This design issue results in failure to start an instance having data volumes and instance snapshots.
2024-06-05 12:16:40,023 INFO  [c.c.h.v.r.VmwareResource] (DirectAgent-101:ctx-79cfdac2 <IP_ADDRESS>, job-38/job-40, cmd: StartCommand) (logid:8e044e50) Tearing down datadisks for deploy-as-is VM
2024-06-05 12:16:40,121 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-101:ctx-79cfdac2 <IP_ADDRESS>, job-38/job-40, cmd: StartCommand) (logid:8e044e50) Error mapping deploy-as-is VM disks from cloned VM i-2-3-VM
java.lang.RuntimeException: Invalid configuration for device '0'.
        at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:426)

STEPS TO REPRODUCE

1. Deploy an instance from a deploy-as-is template with a data volume( Read Instance settings from OVA selected for template).
2. Create an instance snapshot
3. Stop and then start the instance.

EXPECTED RESULTS

The user should be able to perform stop-and-start operations on instances deployed from deploy-as-is template types having data disks and instance snapshots.

ACTUAL RESULTS

The user is unable to stop and start the instance.

I am able to reproduce the issue by the following steps

register a deploy-as-is template
create a vm
create a datadisk and attach to the vm
create vm snapshot
stop the vm
start the vm, and got the same error

note

on vcenter, it shows " Invalid configuration for device '0'. Cannot remove virtual disk from the virtual machine because it or one of its parent disks is part of a snapshot of the virtual machine."
vm can be started successfully in vcenter
vm can be started successfully in cloudstack, after removing the vm snapshot.

it looks the issue is caused by
https://github.com/apache/cloudstack/blob/66f7f76263619c420f922444a1679d2f992c26ab/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java#L2835-L2838
which is called by
https://github.com/apache/cloudstack/blob/66f7f76263619c420f922444a1679d2f992c26ab/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java#L2204-L2207
the code was introduced in #4307 , do you remember why added it and have any idea how to improve it ? cc @nvazquez

Hi @weizhouapache as I do recall there was a similar logic for non-deploy as is VMs but reviewing the code I see those are checking for snapshots. I will review your linked PR

fixed in #9243


[bug] sourceId not working on window level

Describe the bug
When adding the sourceId of a window to the ScreenShareCaptureOptions, still the full screen is being recorded on MacOS build.
To Reproduce

List all sources through rtc.desktopCapturer.getSources
Get id of any of the listed entries (In the example the id of the first window will be taken)
Check published recording

final List<rtc.DesktopCapturerSource> desktopSources = await rtc.desktopCapturer.getSources(types: [rtc.SourceType.Window]);

final room = Room(roomOptions: roomOptions);
try {
await room.connect(_endpointUrl, _accessToken);
await room.localParticipant?.setScreenShareEnabled(true);
var track = await LocalVideoTrack.createScreenShareTrack(
  ScreenShareCaptureOptions(
    maxFrameRate: 15.0,
    sourceId: desktopSources.first.id
  ),
);

await room.localParticipant?.publishVideoTrack(track);

Expected behavior
Only the window of the defined sourceId should be recorded.
Platform information
MacOs Sonoma 14.1.1

Flutter version: Flutter (Channel stable, 3.16.0, on macOS 14.1.1 23B81 darwin-arm64
Plugin version: livekit_client: ^1.5.3
Flutter target OS: MacOs (Desktop)
Flutter target OS version: 14.0
Flutter console log:
As to be noted bellow, the correct sourceId is being logged with type window, but still the full screen is being targeted
2023-11-26 04:53:28.375 digitalsignagereceiverapp[81838:920002] start desktop capture: sourceId: 5026, type: window, fps: 15

Just tested it and it works correctly,
Your code seems to have duplicate parts
If you use
var track = await LocalVideoTrack.createScreenShareTrack(
   ScreenShareCaptureOptions(
     maxFrameRate: 15.0,
     sourceId: desktopSources.first.id
   ),
);

await room.localParticipant?.publishVideoTrack(track);

To publish screen share track, you do not need to run this line
await room.localParticipant?.setScreenShareEnabled(true);

Removing setScreenShareEnabled(true) worked. Thanks!


fuzz on tips (totalOriginalConsiderationItems)

Codecov Report
Patch and project coverage have no change.

Comparison is base (ad302f4) 100.00% compared to head (8a46786) 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##               1.5     #1080    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           46        46
  Lines         2652      2414   -238
  Branches       396       354    -42
==========================================
- Hits          2652      2414   -238

Flag
Coverage Δ

foundry
?

production
100.00% <ø> (ø)

reference
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 29 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Update for precision_n_scores docstring

This was a little confusing for me working with this library, took me a while to figure out the function required raw scores instead of rounded ones (in which case it throws a precision being ill-defined error due to no predicted samples).

Pull Request Test Coverage Report for Build 165

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.076%

Totals

Change from base Build 164:
0.0%

Covered Lines:
2326

Relevant Lines:
2421

💛  - Coveralls


Add columns field as metadata that is explicitly enforced in data check output

Related to https://github.com/alteryx/evalml/issues/2792, perhaps a good way to enforce that all data check return the same fields (ex: "column" vs "columns") is to update the API to enforce this.
This issue tracks updating the API in such a way that will prevent data check outputs from diverging like they currently are. Perhaps one way is to enforce that the output message has a "columns" attribute set.

Closed via #2869


Add support for extended XYZ

The comment line is used to store some metadata, e.g., lattice vectors. See

https://libatoms.github.io/QUIP/io.html#module-ase.io.extxyz
https://github.com/libAtoms/extxyz
https://wiki.fysik.dtu.dk/ase/ase/io/formatoptions.html#extxyz
https://atomsk.univ-lille.fr/doc/en/format_xyz.html

An alternative syntax is:

https://open-babel.readthedocs.io/en/latest/FileFormats/Extended_XYZ_cartesian_coordinates_format.html

Support for extended XYZ was added in 45e40e6ee819067b137fcfc4f099c3bca213a4db based on the specification at https://github.com/libAtoms/extxyz


Because form_builder_validators >=9.1.0 depends on intl ^0.18.1

Is there an existing issue for this?

[X] I have searched the existing issues

Package/Plugin version
1.1.1
Platforms

[ ] Android
[ ] iOS
[X] Linux
[X] MacOS
[X] Web
[X] Windows

Flutter doctor

Flutter doctor

nothing

Minimal code example

Code sample

nothing

Current Behavior
doesn't work
Expected Behavior
update packs
Steps To Reproduce
update packs
Aditional information
sdf

Can't update to intl 0.19 because flutter_localizations (from flutter sdk) use intl0.18.1
Take a look here https://github.com/flutter-form-builder-ecosystem/form_builder_validators/issues/73


Add NpmInstall post-checkout, post-commit, post-merge, and post-rewrite hooks

Planning on adding similar hooks for package managers like bundler and bower. Might be worthwhile to add a base InstallDependencies module since the code will be pretty much identical.

Merged in 3b41109 and 6778db2 (squashed so that the build doesn't break if we were to git bisect).
Thanks!


k8s.IsDeploymentAvailable() sometimes returning true even if de deployment is not complete

Describe the bug
If the test runs too fast, the IsDeploymentAvailable() doesn't correctly check if the deployment is really available. This is an intermittent error. The error does not occur If the deployment was made in the default namespace.
Full Error
$ go test -timeout 30s -tags kubeall -run ^TestKubernetesDeployment$ ./
=== RUN   TestKubernetesDeployment
=== PAUSE TestKubernetesDeployment
=== CONT  TestKubernetesDeployment
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/logger.go:66: Running command kubectl with args [--namespace 08fqcs apply -f ../deploy.yaml]
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/logger.go:66: deployment.apps/nginx created
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/deployment.go:95: Deployment is now available
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/tunnel.go:178: Creating a port forwarding tunnel for resource deploy/nginx routing local port 0 to remote port 80
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/tunnel.go:207: Error finding available pod: Deployment nginx is not available, reason: NewReplicaSetCreated, message: Created new replica set "nginx-765cb4ff6b"
    /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/tunnel.go:173:
                Error Trace:    /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/tunnel.go:173
                                                        /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/deploy_test.go:34
                Error:          Received unexpected error:
                                Deployment nginx is not available, reason: NewReplicaSetCreated, message: Created new replica set "nginx-765cb4ff6b"
                Test:           TestKubernetesDeployment
TestKubernetesDeployment 2023-04-28T23:19:53-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/logger.go:66: Running command kubectl with args [--namespace 08fqcs delete -f ../deploy.yaml]
TestKubernetesDeployment 2023-04-28T23:19:54-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/logger.go:66: deployment.apps "nginx" deleted
TestKubernetesDeployment 2023-04-28T23:19:54-04:00 /home/shotler/github/personal-projects/devops-tools/k8s/operatos/3-deployment/test/client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
--- FAIL: TestKubernetesDeployment (0.15s)
FAIL
FAIL    github.com/marcellmartini/devops-tools/k8s/operatos/3-deployment        0.156s

To Reproduce
Depoyment.yam
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 80

Deployment test
func TestKubernetesDeployment(t *testing.T) {
	t.Parallel()

	kubeResourcePath := "./deploy.yaml"

	uniqueID := strings.ToLower(random.UniqueId())
	options := k8s.NewKubectlOptions("", "", uniqueID)
	k8s.CreateNamespace(t, options, uniqueID)
	defer k8s.DeleteNamespace(t, options, uniqueID)

	k8s.KubectlApply(t, options, kubeResourcePath)
	defer k8s.KubectlDelete(t, options, kubeResourcePath)

	k8s.WaitUntilDeploymentAvailable(t, options, "nginx", 60, 1*time.Second)

	// Open a tunnel to Deployment from any available port locally
	tunnel := k8s.NewTunnel(options, k8s.ResourceTypeDeployment, "nginx", 0, 80)
	defer tunnel.Close()
	tunnel.ForwardPort(t)

	// Setup a TLS configuration to submit with the helper, a blank struct is acceptable
	tlsConfig := tls.Config{}

	// Try to access the nginx service on the local port, retrying until we get a good response for up to 5 minutes
	http_helper.HttpGetWithRetryWithCustomValidation(
		t,
		fmt.Sprintf("http://%s", tunnel.Endpoint()),
		&tlsConfig,
		60,
		5*time.Second,
		verifyNginxWelcomePage,
	)
}

Expected behavior
$ go test -timeout 30s -tags kubeall -run ^TestKubernetesDeployment$ ./
=== RUN   TestKubernetesDeployment
=== PAUSE TestKubernetesDeployment
=== CONT  TestKubernetesDeployment
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./logger.go:66: Running command kubectl with args [--namespace zy5a2w apply -f ../deploy.yaml]
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./logger.go:66: deployment.apps/nginx created
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:14-04:00 ./retry.go:103: Wait for deployment nginx to be provisioned. returned an error: Deployment nginx is not available, reason: NewReplicaSetCreated, message: Created new replica set "nginx-765cb4ff6b". Sleeping for 1s and will try again.
TestKubernetesDeployment 2023-04-28T23:24:15-04:00 ./retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:24:15-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:15-04:00 ./retry.go:103: Wait for deployment nginx to be provisioned. returned an error: Deployment nginx is not available, reason: MinimumReplicasUnavailable, message: Deployment does not have minimum availability.. Sleeping for 1s and will try again.
TestKubernetesDeployment 2023-04-28T23:24:16-04:00 ./retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:24:16-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:16-04:00 ./retry.go:103: Wait for deployment nginx to be provisioned. returned an error: Deployment nginx is not available, reason: MinimumReplicasUnavailable, message: Deployment does not have minimum availability.. Sleeping for 1s and will try again.
TestKubernetesDeployment 2023-04-28T23:24:17-04:00 ./retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:24:17-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:17-04:00 ./retry.go:103: Wait for deployment nginx to be provisioned. returned an error: Deployment nginx is not available, reason: MinimumReplicasUnavailable, message: Deployment does not have minimum availability.. Sleeping for 1s and will try again.
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./retry.go:91: Wait for deployment nginx to be provisioned.
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./deployment.go:95: Deployment is now available
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:178: Creating a port forwarding tunnel for resource deploy/nginx routing local port 0 to remote port 80
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:210: Selected pod nginx-765cb4ff6b-lwzjp to open port forward to
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:223: Using URL https://<IP_ADDRESS>:8443/api/v1/namespaces/zy5a2w/pods/nginx-765cb4ff6b-lwzjp/portforward to create portforward
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:240: Requested local port is 0. Selecting an open port on host system
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:246: Selected port 37927
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./tunnel.go:272: Successfully created port forwarding tunnel
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./retry.go:91: HTTP GET to URL http://localhost:37927
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./http_helper.go:59: Making an HTTP GET call to URL http://localhost:37927
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./logger.go:66: Running command kubectl with args [--namespace zy5a2w delete -f ../deploy.yaml]
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./logger.go:66: deployment.apps "nginx" deleted
TestKubernetesDeployment 2023-04-28T23:24:18-04:00 ./client.go:42: Configuring Kubernetes client using config file /home/shotler/.kube/config with context
--- PASS: TestKubernetesDeployment (4.18s)
PASS
ok      github.com/marcellmartini/devops-tools/k8s/operatos/3-deployment        4.194s

Fix released in https://github.com/gruntwork-io/terratest/releases/tag/v0.41.22


py2: sleep before teardown

@tchaikov is this how we should backport PRs to py2?

hi @kshtsk i

edit the title of this PR, to add "py2:" before it.
created "py2" milestone and added this PR to it, to differentiate PR targeting master from "py2" branch.

as you mentioned, py2 branch will be "minimal", and i think it is now in its maintenance mode, ideally only bug fixes will goto that branch.
presumably, --sleep-before-teardown option is a feature. but i guess you have good reason to add it to py2 branches as well for tracking bugs.

@kshtsk are you actively testing LTS branches? i am asking because currently the only guy who is actively testing LTS branches is @yuriw , so i want to minimize the risk that he run into any issue because of the backports. another consumer of py2 branch is cron job.

@tchaikov depends on what you mean "actively". We still running suse downstream tests in py2 development. Also it is possible to run deploy test on py2 based branches. Good thing that back ports are already tested on py3 tests. If you run ceph named branches, that is another case. Also I would like to keep py2 and py3 be as close as possible, in sense of features and documentation.

@tchaikov depends on what you mean "actively". We still running suse downstream tests in py2 development. Also it is possible to run deploy test on py2 based branches. Good thing that back

that explains. i thought "py2" branch should be in maintenance mode. but since you guys are still using it for testing, it's relatively safe for backporting features.

ports are already tested on py3 tests. If you run ceph named branches, that is another case. Also I would like to keep py2 and py3 be as close as possible, in sense of features and documentation.

okay, as long as you are still using it. that's a relief. my major concern was we were backporting features and unlike the changes in master, the backport changes were not well tested.


chore: project addition by Harshu467 #1869

Project Addition
Regarding Issue Number #1869
Description
Added Machine Learning Project of water Quality Prediction

Please check and Merge

Please Add label of GSOC and level @priyankarpal

Please Add label of GSOC and level @priyankarpal

We are not providing any labels for project additions as they are not associated with solving any issues.( according to gssoc23 rules)

So they dont count for GSOC score?

So they dont count for GSOC score?

nope. only for projects addition we're not providing any labels


Feature/14 tidying

Closes #14

Coverage remained the same at 92.958% when pulling 5409ddf969e1c1182dcca0aa01aba389a8b2c48d on feature/14-tidying into ab7889ee4b99353f1056e07ec27325d698488f53 on master.


[Definition] Just search for changed specs in an exactly matching source

\c @indirect

This fixes things for me! 🏆 @homu r+

:pushpin: Commit 9cbf8fb has been approved by indirect

:hourglass: Testing commit 9cbf8fb with merge faf82cc...

:sunny: Test successful - status


Document Viewer: Unable to load cmap

Describe the bug
When viewing a PDF with no embedded fonts, the requested CMap resource path is incorrect.
A resource path such as "/jakarta.faces.resource/web/cmaps/Adobe-Japan1-UCS2.bcmap" is requested, but a 404 error occurs.
Reproducer
No response
Expected behavior
No response
PrimeFaces Extensions version
12.0.8
JSF implementation
None
JSF version
No response
Browser(s)
No response

Do you have an example PDF I can test with?

Please check the PDF at the URL below.
https://www.courts.go.jp/app/files/hanrei_jp/097/075097_hanrei.pdf

Thanks that will help me debug it!

Thanks fixed in 12.0.9 and 13.0.0.  12.0.9 should be in Maven Central in a couple of hours


Failed validity check on papirus-folders

Greetings
Im still getting a failed validity check when trying to install papirus-folders-catppuccin-git using an AUR helper (paru)
The error seems to be validating papirus-folders checksum fails
==> Validating source files with md5sums...
    papirus-folders-catppuccin-git ... Skipped
    papirus-folders.hook ... Passed
    papirus-folders ... FAILED

Checking the PKGBUILD in the AUR for papirus-folders-catppuccin-git, i can see that the checksum for papirus-folder is not SKIP, but instead 07398d48f6d86df3573fafc612c9c198. I dont know if this repo links to a different AUR package or not.
But in any case, the md5 sum for papirus-folders is not wrong. I downloaded papirus-folders from the link from the link in PKGBUILD and md5sum the downloaded file. The result is here:
md5sum papirus-folders
07398d48f6d86df3573fafc612c9c198  papirus-folders

Which matches with the PKGBUILD of papirus-folders-catppuccin-git.
I dont know why it is failing.
Host details:
Arch x86_64
6.9.4-arch1-1
paru v2.0.3 - libalpm v14.0.0
Originally posted by @sudoAlphaX in https://github.com/catppuccin/aur-packages/issues/34#issuecomment-2167268322

I think the latest PR should have fixed this issue @sudoAlphaX.
Feel free to comment if it's not and I can re-open this issue!

papirus-folders-catppuccin-git now installs without any errors using paru AUR helper, and I can see that papirus-folders checksum is being skipped.
Thank you for your help @sgoudham.
Have a great rest of your day!

This is so silly.
I am not getting any output from executing papirus-folders command.
I uninstalled papirus-folders-catppuccin-git and installed papirus-folders-git, and compared the /usr/bin/papirus-folders file, which is what i got from executing whereis papirus-folders.
The papirus-folders executable differs for the two packages.
Here are the contents of the executable from papirus-folders-catppuccin-git: https://pastebin.com/bRxAuEje
And here are the contents from papirus-folders-git: https://pastebin.com/WynnL17K
The contents are very much different from each other:  https://pastebin.com/LHJutx80
Sorry to bother you once again

I do not have much experience with the Arch build system, but ill try my best to find the issue and open a PR if i can.

I figured out the issue.
Turns out, since the CI only pushed PKGBUILD and .SRCINFO, the old papirus-folders script was still present in the AUR repo upstream.
Can you try building this again and let me know if this fails now or not?

Nope, still facing the same issue. I just uninstalled papirus-folders-git along with configuration files and protected data using -Rcns flag, and cleared pacman and paru cache using -Sc. I then reinstalled catppuccin-folders-catppuccin-git. Nothing changed.

I do not understand why this line exists in the PKGBUILD:
  "papirus-folders::https://raw.githubusercontent.com/PapirusDevelopmentTeam/papirus-folders/master/papirus-folders") and i download that file and its the proper papirus-folders script, but if the same is done using paru, it fetches another papirus-folders script.
Maybe its my AUR helper that has bugs. Let me install yay and report the results.

We need the file since upstream papirus script now supports custom colours and we add it as a source, and apparently it works correctly in our and ci and even tested successfully by someone else on our discord server.
I'm pretty confused about why this is happening now.

This seems to be an issue specific to me. I just created an arch vm (fresh install) and installed paru in it. Then I installed papirus-folders-catppuccin-git. papirus-folders command is working well.

I just installed yay (Another AUR Helper) on my main machine and installed papirus-folders-catppuccin-git using yay, and now, papirus-folders command is again working correctly.

I uninstalled papirus-folders-catppuccin-git (installed using yay) and cleared cache of paru and tried installing again. Same result. Somehow, that particular app is not getting installed using paru on my specific machine, because it worked in the VM.
Really interesting...

I tried reinstalling paru but still got the same result.
But when I tried installing papirus-folders-catppuccin-git with verbose flag, i noticed this line:
Targets   : /home/alpha/.cache/paru/clone/papirus-folders-catppuccin-git/papirus-folders-catppuccin-git-r30.f83671d1-2-any.pkg.tar.zst
I thought maybe the cache wasnt getting flushed, so i just deleted everything in $HOME/.cache folder and tried reinstalling the tool again.
And this time, it finally worked. 'papirus-folders' command was giving a proper output, and im able to change the folder colors.
What had happened is paru kept trying to use the pre-downloaded .tar.gz to reinstall the utility.
Anyways, thank you very much for your support @ghostx31. Have a wonderful weekend.

Glad you figured this out!


Fix fastlane build by freeing extra space

Root cause is https://github.com/actions/runner-images/issues/10511