Taskruns: hard to follow steps status of a task

Consider the following task
...
kind: Task
...
spec:
  steps:
    - name: echo1
      image: ubuntu
      command:
        - echo
      args:
        - "hello world 1"
    - name: echo2
      image: ubuntu
      command:
        - echo
      args:
        - "hello world 2"

Once the user executes a such Task using Taskrun the status appears like as follow
status:
  conditions:
  - lastTransitionTime: "2019-02-22T05:22:48Z"
    status: "True"
    type: Succeeded
  podName: echo-hello-world-task-run-pod-c1eaa6
  startTime: "2019-02-22T05:22:15Z"
  steps:
  - logsURL: ""
    terminated:
      containerID: docker://c317b86c9aa06e9ec6d167fc67b819fc8c023010804a6cf69f64fbaaf92acde8
      exitCode: 0
      finishedAt: "2019-02-22T05:22:17Z"
      reason: Completed
      startedAt: "2019-02-22T05:22:17Z"
  - logsURL: ""
    terminated:
      containerID: docker://dd36b9b1d1f5f5181f51ab54ba491b2df99ff25a39daf72d6888c9ad8549e1b5
      exitCode: 0
      finishedAt: "2019-02-22T05:22:22Z"
      reason: Completed
      startedAt: "2019-02-22T05:22:22Z"
  - logsURL: ""
    terminated:
      containerID: docker://5c4077eee28c6b254e09456ad26533ace5644adf341ea589344eb6c186857a7f
      exitCode: 0
      finishedAt: "2019-02-22T05:22:28Z"
      reason: Completed
      startedAt: "2019-02-22T05:22:28Z"

Now as a user I'm not able to determine the status of individual steps.  This be might be addressed in #146
Expected Behavior
It's better to associate step name in the individual step status.
Actual Behavior
Taskrun step status doesn't have any association/mapping between step information and its status.
Also wondering 3rd step in the status though task mentions only 2 steps.
Steps to Reproduce the Problem

Create a Task
Create Runtask

Thanks for opening this @hrishin ! That's a good point - I think I usually work around this by going straight to the pod itself but that's quite a pain and it would be useful to have more info in the TaskRun status directly.
Looking at StepState it's pretty much just corev1.ContainerState right now. If we add in the step names for each of these, does that do the trick @hrishin or is there more info that you already know you'd want?
(In the future we might want to consider including more info from the pod status maybe :thinking: )
Note to the implementer: We support unnamed steps as well.

I think I usually work around this by going straight to the pod itself but that's quite a pain and it would be useful to have more info in the TaskRun status directly.

Yes, it's painful.

Looking at StepState it's pretty much just corev1.ContainerState right now. If we add in the step names for each of these, does that do the trick

@bobcatfish I think we need container name (it may be init-container name) for stepstate or taskstate along with whether it's waiting, running, terminated. At this moment we don't have any association between state and step, right?. As a progressive step, it would be better to have logUrl or logBlob which we are going to address in #107, I guess. right?

Let me run the task and pipelines, will post more updates about it. However containerstatus looks good enough.

For task and taskrun, the following kind of status could be helpful:
status:
  conditions:
  - lastTransitionTime: "2019-03-06T06:27:41Z"
    status: "True"
    type: Succeeded
  podName: echo-hello-world-task-run-pod-58fa47
  taskName: echo-hello-world
  startTime: "2019-03-06T06:25:57Z"
  steps:
  - name: "credential-initializer"
    terminated:
      containerID: docker://3231c9736b099b57cbac3000b5fa118617af065816a8db9b9783a5ee9d8b5ad3
      exitCode: 0
      finishedAt: "2019-03-06T06:26:38Z"
      reason: Completed
      startedAt: "2019-03-06T06:26:38Z"
  - name: "echo1"
    terminated:
      containerID: docker://91f963a2bb984ec85b3355e32c0755c3b75fa1e5ae420b5984d817de9b7188b4
      exitCode: 0
      finishedAt: "2019-03-06T06:26:51Z"
      reason: Completed
      startedAt: "2019-03-06T06:26:51Z"
  - name: "echo1"
    terminated:
      containerID: docker://f5e8a13a9a91859dfd6912187f0bf9851213e215d9d75ec22bd132174c9da10e
      exitCode: 0
      finishedAt: "2019-03-06T06:26:58Z"
      reason: Completed
      startedAt: "2019-03-06T06:26:58Z"

where task definition is
spec:
  steps:
    - name: echo1
      image: ubuntu
      command:
        - echo
      args:
        - "hello world 1"
    - name: echo2
      image: ubuntu
      command:
        - echo
      args:
        - "hello world 2"

So

taskName:  represents the the actual task name from definition
.steps.name: represents the actual name of each step from definition

This could help in exact UI/Visual presentation of a pipeline. This could also be useful for doing benchmarking of steps, task and whole pipeline (i.e. exporting metrics in Prometheus).

For unnamed steps, I'm really not sure. Maybe putting sequence number with step names could be possible options like
status:
  conditions:
  - lastTransitionTime: "2019-03-06T13:04:21Z"
    status: "True"
    type: Succeeded
  podName: test-unnamed-steps-pod-64c75b
  startTime: "2019-03-06T13:03:23Z"
  steps:
  - name: "step 1"
    terminated:
      containerID: docker://010bb14c157024726a8b2261c8f4ef5d5d4162b37ef8daa7c7ddd76ba60f3b81
      exitCode: 0
      finishedAt: "2019-03-06T13:03:26Z"
      reason: Completed
      startedAt: "2019-03-06T13:03:26Z"
  - name: "step 2"
    terminated:
      containerID: docker://d6a59e9fdf236966cb9788cbed45525cdef31b214d7e113d1035d201d9efabe3
      exitCode: 0
      finishedAt: "2019-03-06T13:03:33Z"
      reason: Completed
      startedAt: "2019-03-06T13:03:33Z"
  - name: "step 3"
    terminated:
      containerID: docker://cd9de32bf993dcd45492f0768b134e258779fc1eff895658bc578b78587f4841
      exitCode: 0
      finishedAt: "2019-03-06T13:03:42Z"
      reason: Completed
      startedAt: "2019-03-06T13:03:42Z"

Any reason we are allowing unnamed steps in a task? what would happen if mandate name to each step?

@bobcatfish the latest code does not allow user to use unnamed step, is it right? when I apply a task that has unnamed steps, the below error will be printed
Error from server (InternalError): error when creating "uname-steps-task.yaml": Internal error occurred: admission webhook "webhook.tekton.dev" denied the request: mutation failed: invalid value "": taskspec.steps.name
Task step name must be a valid DNS Label, For more info refer to https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

I send out a PR to add a step name to taskrun status

Hi @skeeey
What do you mean by latest code? I've tried from last release, there unamed task is working.
Hi @bobcatfish @vdemeester @ImJasonH
Could you please confirm if we have dropped the support for unamed steps?

@hrishin not the last release, I build the master code, :-)

(Stumbled across this going through good-first-issues)
Is this still an issue?
We still support unnamed steps. If a user doesn't name a step, it's corresponding container name in the Pod will be step-unnamed-N where N  is the index in the original steps list.

/close


rbe: no cache hits when building ios_profile

reproduction
./flutter/bin/et build -c ios_profile
reproxy status
$ buildtools/mac-arm64/reclient/reproxystatus
Reproxy(unix:///tmp/reproxy.sock) is OK
Actions completed: 2638 (2350 racing locals, 288 racing remotes)
Actions in progress: 16
QPS: 9

git hash
f66a847a9ecd20168696114b409a454b8d3ff879 with local changes to just impeller/entity/contents/filters/gaussian_blur_filter_contents.cc
expected behavior
I'd expect most compilations to be a cache hit except gaussian_blur_filter_contents.cc
xcode version
$ xcodebuild -version
Xcode 15.0
Build version 15A240d

network
google office wifi
OS
macos 14.5

Here's a copy of the log from /tmp
reproxy_2024-06-26_15_08_38.rrpl.zip

@zanderso let me know if there is any other information I should provide.

I am looking into reconfiguring the worker pool to match the configuration that chrome uses.

I landed a change to reconfigure the worker pool. Over the next week, I'm going to monitor build times on CI. @gaaclarke could you also keep an eye on your local build stats to see whether there's any improvement, particularly during peak hours in the afternoon PDT.

@gaaclarke Still seeing this issue?

@gaaclarke Still seeing this issue?

I haven't noticed it.  I rarely build the profile build but I did it a few times last week and didn't notice anything.

@gaaclarke Let's close this issue then so we aren't tracking things we don't think are important to fix or address.


decompressor filter: add bytes reporting to trailers

Commit Message: add bytes reporting to trailers
Additional Description: it is useful for certain experiments to be aware of the compressed/uncompressed size of payloads as they go through the decompressor filter. This PR adds such details to the request/response trailers.
Risk Level: low
Testing: updated unit and integration tests
Docs Changes: updated
Release Notes: updated
Signed-off-by: Jose Nino<EMAIL_ADDRESS>

@rojkov do you mind taking a pass at this?
@rebello95 if you want to take a pass too.

I'm on holidays till the middle of August. I'll be happy to give it a pass later if it's still open.

@dio do you mind taking a look given @rojkov is out?

coming back to this after being completely occupied otherwise.

@dio can I get a re-review now that I updated and de-staled the PR?


Itinerary step-by-step tweaks

Description
Tweak some style on the step-by-step mode to closely match the design:

color of the back arrow
margins/paddings of elements
remove the ellipsis gradient

Screenshots

Before
After

Shoudn't we still display an ellipsis in order to inform the user there is more content than actually displayed ?

Shoudn't we still display an ellipsis in order to inform the user there is more content than actually displayed ?

@G-Ray I've used line clamping which adds a … ellipsis indicator. More complex solutions seem far-fetched to me.

@G-Ray I've used line clamping which adds a … ellipsis indicator. More complex solutions seem far-fetched to me.


[BUG] cluster state  stuck at "Waiting for etcd snapshot creation management plane restart probes"

Rancher Server Setup

Rancher version: 2.8.4
Installation option (Docker install/Helm Chart): docker

Information about the Cluster

Kubernetes version: 1.28.9-k3s
Cluster Type (Local/Downstream): Downstream

Describe the bug
After a node crash the cluster state is  stuck at
'''Waiting for etcd snapshot creation management plane restart probes'''
All operations can be performed normally, so this is more a  cosmetic bug
To Reproduce
Not really known
Expected Result
cluster recovers fully from node crash after some time or a manual workaround to reset this state.
Additional  Informations
both rancher upgrade 2.8.3 -> 2.8.4  and k3s version upgrade (1.27.x -> 1.28.x) went smoothly, but did not reset this message.

It seems this was caused by outdated certificates on one node. After clearing the old certs (following https://github.com/rancher/rancher/issues/41125#issuecomment-1506620040) the node updated successfully.


CH has some limitations on translate function, but velox doesn't

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

Fixed.


Supports options when creating conversion jobs

Adds support for an options array to $jobs->create(), allowing users to override conversion customisations.
Allows the underlying Guzzle HTTP client to be customised via a new $config['transport'] option

I've tested this via the following:
$job = $zamzar->jobs->create([
    'source_file' => '/Users/louis/Downloads/sample.txt',
    'target_format' => 'mp3',
    'options' => [
        'voice' => 'en.female'
    ]
]);

which works when using this branch; but fails on main with:
PHP Fatal error:  Uncaught InvalidArgumentException: Invalid resource type: array in /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/psr7/src/Utils.php:341
Stack trace:
#0 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/psr7/src/MultipartStream.php(94): GuzzleHttp\Psr7\Utils::streamFor(Array)
#1 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/psr7/src/MultipartStream.php(77): GuzzleHttp\Psr7\MultipartStream->addElement(Object(GuzzleHttp\Psr7\AppendStream), Array)
#2 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/psr7/src/MultipartStream.php(38): GuzzleHttp\Psr7\MultipartStream->createStream(Array)
#3 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/guzzle/src/Client.php(372): GuzzleHttp\Psr7\MultipartStream->__construct(Array)
#4 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/guzzle/src/Client.php(328): GuzzleHttp\Client->applyOptions(Object(GuzzleHttp\Psr7\Request), Array)
#5 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/guzzle/src/Client.php(169): GuzzleHttp\Client->transfer(Object(GuzzleHttp\Psr7\Request), Array)
#6 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/guzzle/src/Client.php(189): GuzzleHttp\Client->requestAsync('POST', Object(GuzzleHttp\Psr7\Uri), Array)
#7 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/zamzar/zamzar-php/lib/HttpClient/GuzzleClient.php(26): GuzzleHttp\Client->request('POST', 'https://api.zam...', Array)
#8 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/zamzar/zamzar-php/lib/ApiRequestor.php(56): Zamzar\HttpClient\GuzzleClient::request(Array, 'https://api.zam...', 'POST', Array, true, false)
#9 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/zamzar/zamzar-php/lib/BaseZamzarClient.php(84): Zamzar\ApiRequestor->request('https://api.zam...', 'POST', Array, false)
#10 /Users/louis/Code/Zamzar/try-zamzar-php/vendor/zamzar/zamzar-php/lib/Service/JobService.php(12): Zamzar\BaseZamzarClient->request('POST', '/v1/jobs', Array)
#11 /Users/louis/Code/Zamzar/try-zamzar-php/src/Try.php(15): Zamzar\Service\JobService->create(Array)
#12 {main}
  thrown in /Users/louis/Code/Zamzar/try-zamzar-php/vendor/guzzlehttp/psr7/src/Utils.php on line 341

Paging @zamzar-miked @Nawv -- please could I have a review before looking to release this as a new patch version of the library?

@louismrose Lgtm 👍 (I tested both job creation using options and the Guzzle client customisation; both worked well).

Thank-you both for the review. Releasing now 🚢 🎉


Update GZip.jl

Remove deprecation warnings in latest 0.4

Probably needs JuliaLang/Compat.jl#107 not to break 0.3

of course. One sec.

Not sure why that test is failing.

because https://github.com/JuliaLang/Compat.jl/issues/107 has not been fixed or tagged yet

I have no idea why, but with these deprecation warnings the GC state was not turning back on for me. Could it be because of depwarn()? So +1 to merging this PR ASAP.
Also, should the GC state be saved and restored to the original one instead of "true"?

I just tagged a Compat.jl release that implements JuliaLang/Compat.jl#107. But there's no need to use the @compat macro here.

I restarted the build (which should pass), but as @simonster pointed out, you should remove @compat, as nothing needs to be rewritten.

@sbromberger Looks good. Squash the commits?

Not easily, I don't think - I edited within github.

Okay, I pushed your first commit to master b998284b9627361cab8c3a22e00191d19a1c09d1

Thanks. Sorry - I've been out all day.

No problem. Thanks for tracking down and fixing the issue.

My pleasure. Would you mind tagging so I can update my REQUIRE? Thanks!

Pending in JuliaLang/METADATA.jl#2824

Awesome! Thanks again.


correct propagation of changes

The previous implementation was incorrect and didn't make sure that
"changes" are propagated to all the influenced statements.
The essential issue here is that, without usage information of argument
or SSA values, this backward analysis doesn't fully understand which
statement can be affected by this statement (by contrast a forward
analysis can just use Goto and GotoIfNot in order to respect the
control flow, and they are always available at inference).
Let me explain the problem with an example; a current implementation end
up with a single traversal and will produce the following result
%1 = alloc
%2 = escape!(%1)        # %1 => escape
%3 = alloc
%4 = setfield!(%1, %3)  # (we have to come back to this statement after %2, and mark %3 also escape)
     return %3          # %3 => return escape

(NOTE: currently this code actually "works", because I've not implemented
the setfield! handling yet, and it conservatively escapes all its arguments
right now)
This is because the change of %2 doesn't propagate to %4.
To fix this "properly", we need to construct a mapping of
(argument, SSA values) -> (argument usages, SSA value usages) and propagate changes from the current statement to all usages and definitions.
This PR right now rather simply keeps linear traversing until every
statement gets converged and it should also be a valid fix (but maybe
less efficient).
We may want to implement the "correct" fix and compare their performances.

@vtjnash does this explanation sound right ? I'd like to know if you have any insights.
@TH3CHARLie do you want to try the "proper" fix ? Core.Compiler.find_ssavalue_uses would be a good reference to construct the mapping.

Probably better seen within whitespace-less view: https://github.com/aviatesk/EscapeAnalysis.jl/pull/2/files?diff=unified&w=1

I would love to try to build the mapping and thanks for the pointer.

Thanks for your reviews.

if we successfully construct and maintain a mapping from SSAValue to its use sites, we will be able to reflect the change quickly which may lead to fewer iterations.

Yes, as for benchmarking, something like below might help:
function benchmarkjit(f, tt)
    EscapeAnalysis.__clear_caches!()
    analyze_escapes(f, tt)
end


Sending audio to camera - connection not closed after sending

Hello,
first of all thanks for the great application.
I am sending audio to a Tapo C320WS like in the example via POST request:
ffmpeg:https://example.com/song.mp3#audio=pcma#input=file
Result: audio is playing fine on the camera.
Issue: A constant noise comes out of the camera speakers after playing. Furthermore the Tapo app itself can't access the camera speakers anymore, with an error, that the camera is occupied. Sending another audio via POST request is possible, but the noise is always there afterwards.
Restart of the camera helps - but is there a better solution to fully close the connection after sending audio?

Check stream info after playing

for producer
"type": "Tapo active producer"
the additional
"senders": ["8 PCMA/8000, bytes=21696, receivers=1"]
is returned on stream info. Shouldn't this be removed automatically after sending?
The PATCH from the API just updates the stream source - so I don't see how to delete these senders with a request!?

Are bytes changing when you refresh info?

The bytes in the senders array not, no.
The bytes in the receivers array are increasing of course.
I found out now, that after ~20min the senders got removed - but would be great if there was an option to remove instantly after the 3 second audio file.  This makes it hard to analyze the problem

Sorry - I have no clue what information is missing.


Sample Execution Error

Hello.
I am trying to execute the first example code of AI-Feynman, following its GitHub repository procedure.
I have done $ pip install aifeynman, and executed the below codes at the REPL.
import aifeynman
aifeynman.get_demos("example_data") # Download examples from server
aifeynman.run_aifeynman("./example_data/", "example1.txt", 60, "14ops.txt", polyfit_deg=3, NN_epochs=500)

The code has been started, but it output an error message "STOP DEATH ERROR: missing file args.dat" with the following stdout statements.
Checking for brute force +

Trying to solve mysteries with brute force...
Trying to solve ./example_data/example1.txt_train
STOP DEATH ERROR: missing file args.dat
Checking for brute force *

Trying to solve mysteries with brute force...
Trying to solve ./example_data/example1.txt_train
STOP DEATH ERROR: missing file args.dat
Checking polyfit

Pareto frontier in the current branch:

Complexity #  MDL Loss #  Expression
820.58 23.51 -3.97366916299281e-9*x0**3 - 4.98792375183732e-6*x0**2*x1 - 2.34615280130395e-5*x0**2*x2 + 0.000207395709218903*x0**2 - 0.000127172549695894*x0*x1**2 - 0.0297271185372981*x0*x1*x2 + 0.253671372975734*x0*x1 + 0.00425288419012183*x0*x2**2 - 0.0277197179641274*x0*x2 + 0.932555887619613*x0 - 0.000233584852340369*x1**3 - 0.0590672539598628*x1**2*x2 + 0.504778926577637*x1**2 + 0.0253291848989736*x1*x2**2 - 0.131143431894439*x1*x2 - 0.651859763950773*x1 - 0.00362777965859679*x2**3 + 0.0321967297940855*x2**2 - 0.0913890606187051*x2 + 0.614004068741101

Checking for brute force +

Trying to solve mysteries with brute force...
Trying to solve results/mystery_world_squared/example1.txt_train
STOP DEATH ERROR: missing file args.dat
Checking for brute force *

(These lines above are repeated...)

My environment was constructed on an AWS VM based on the Deep Learning AMI of Ubuntu 18.04,
and its pre-installed conda environment with py36 & torch was activated.
I would appreciate it if you could tell me how to solve this problem. Thank you very much.

Are you sure it is not a problem of rights ? maybe open up the file permissions with chmod (see §4 of https://towardsdatascience.com/ai-feynman-2-0-learning-regression-equations-from-data-3232151bd929 )


[Bug]: KeyError: 'covariate_type'

Do you need to file an issue?

[X] I have searched the existing issues and this bug is not already filed.
[ ] My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
[ ] I believe this is a legitimate bug, not just a question. If this is a question, please use the Discussions area.

Describe the bug
claim_extraction:
llm: override the global llm settings for this task
parallelization: override the global parallelization settings for this task
async_mode: override the global async_mode settings for this task
enabled: true
prompt: "prompts/claim_extraction.txt"
prompt: ${GRAPHRAG_CLAIM_EXTRACTION_PROMPT_FILE}
description: "Any claims or facts that could be relevant to information discovery."
max_gleanings: 1
This is the config i setted
Steps to reproduce
No response
Expected Behavior
No response
GraphRAG Config Used
# Paste your config here

Logs and screenshots
No response
Additional Information

GraphRAG Version:
Operating System:
Python Version:
Related Issues:

Can you upload you indexing-engine.log? It would be helpful to see if there are errors during claim extraction

您可以上传 indexing-engine.log 吗？查看索赔提取过程中是否存在错误会很有帮助

indexing-engine.log
My error is also KeyError: 'covariate_type', and the above is my log file

您可以上传 indexing-engine.log 吗？查看索赔提取过程中是否存在错误会很有帮助

indexing-engine.log My error is also KeyError: 'covariate_type', and the above is my log file

This log looks like it is having HTTP timeouts, indicating your deployment may not be responding correctly. It also looks like when it does respond, there may be issues with the JSON formatting.


Errors while adding the Calendar component

I have a new install using Next13 with create-next-app enabling the experimental app directory and  and then npx shadcn-ui init. When I try to install the calendar component, I get errors:
❯ npx shadcn-ui add calendar
Running the following command will overwrite existing files.
Make sure you have committed your changes before proceeding.

✔ Where would you like to install the component(s)? … ./components/ui
Installing 1 component(s) and dependencies...
⠦ Calendar...file:///home/mike/.npm/_npx/74755fd285ad77f7/node_modules/execa/lib/error.js:59
                error = new Error(message);
                        ^

Error: Command failed with exit code 1: npm install react-day-picker date-fns
npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name "react-day-picker date-fns" of package "react-day-picker date-fns": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! A complete log of this run can be found in: /home/mike/.npm/_logs/2023-04-19T01_54_22_545Z-debug-0.log
    at makeError (file:///home/mike/.npm/_npx/74755fd285ad77f7/node_modules/execa/lib/error.js:59:11)
    at handlePromise (file:///home/mike/.npm/_npx/74755fd285ad77f7/node_modules/execa/index.js:124:26)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Command.<anonymous> (file:///home/mike/.npm/_npx/74755fd285ad77f7/node_modules/shadcn-ui/dist/index.js:406:9) {
  shortMessage: 'Command failed with exit code 1: npm install react-day-picker date-fns',
  command: 'npm install react-day-picker date-fns',
  escapedCommand: 'npm install "react-day-picker date-fns"',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout: '',
  stderr: 'npm ERR! code EINVALIDTAGNAME\n' +
    'npm ERR! Invalid tag name "react-day-picker date-fns" of package "react-day-picker date-fns": Tags may not have any characters that encodeURIComponent encodes.\n' +
    '\n' +
    'npm ERR! A complete log of this run can be found in: /home/mike/.npm/_logs/2023-04-19T01_54_22_545Z-debug-0.log',
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}

Node.js v19.9.0

Executing npm install react-day-picker date-fns manually does not produce any errors:
❯ npm install react-day-picker date-fns

added 2 packages, and audited 370 packages in 4s

120 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

I'm using:
Node.js v19.9.0
NPM 9.6.4

This is fixed. The date-fns dependency was missing.

Yes, it is working for me now. Thanks.

Hm, today i've tried install calendar via npx shadcn-ui add calendar and get the same error

@Blinks44 Which version of shadcn-ui are you using and which package manager?

@shadcn package manager - npm, but i don't understand about version of shadcn-ui, i've just created fresh project -> npx shadcn-ui init -> npx shadcn-ui add calendar -> and booom, error.
Oh, and i don't use Next.js 13, just wanted to play around in Vite, all components work fine except the calendar.

Okey, now i know, that this is how npx is designed. To always use latest version of package preferable way is npx shadcn-ui@latest add calendar and problem is fixed

@Blinks44 @shadcn Yea I think the docs would be better to tell the reader to always use npx shadcn-ui@latest then to prevent this problem.


⚠ Bofrost.at has degraded performance

In 068cd5a, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1425 ms

Resolved: Bofrost.at performance has improved in d345b05 after 7 minutes.


Merge branch 'main' into Omzig/noissue1

ugg, git hate me

active directory is in a nested folder that the build.ps1 does not like:
Publish-PSResource: /home/runner/work/scripts/scripts/build.ps1:10
Line |
  10 |      Publish-PSResource -Repository PSUScriptLibrary -Path $_.FullName
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Module manifest file validation failed with error: The specified
     | RequiredModules entry 'ActiveDirectory.Scripts' in the module manifest
     | '/home/runner/work/scripts/scripts/Apps/PowerShell/ActiveDirectory/Apps.PowerShell.ActiveDirectory.psd1' is invalid. Try again after updating this entry with valid values.. Run 'Test-ModuleManifest' to validate the module manifest.
Error: Process completed with exit code 1.

@adamdriscoll, i tried to get the container to be happy with the module location, but for some reason i cannot get the build to work, if you have time would you mind to look at it? i can run the build local on my computer but it just doesn't work the same way in the container.

@Omzig Thanks for giving it a shot. I can take a look too.

@adamdriscoll, i got it working based on this https://github.com/PowerShell/PowerShell/issues/7722#issuecomment-581539728


Update avalonia refrence to 0.10.999-cibuild0020667-beta

We're not going to merge this one in, we're just using this branch to publish a fork of the packages in this repo that are compatible with the Avalonia nightly build.


Feature/status batches for linter results

Codecov Report

Merging #10 (8fc0606) into master (7b89cbe) will decrease coverage by 2.15%.
The diff coverage is 16.66%.

@@             Coverage Diff              @@
##             master      #10      +/-   ##
============================================
- Coverage     87.47%   85.31%   -2.16%
  Complexity       85       85
============================================
  Files            69       70       +1
  Lines           982     1008      +26
  Branches         72       79       +7
============================================
+ Hits            859      860       +1
- Misses           85      110      +25
  Partials         38       38

Impacted Files
Coverage Δ
Complexity Δ

web-ui/src/client/app/components/violations.jsx
88.88% <ø> (ø)
0.00 <0.00> (ø)

web-ui/src/client/app/containers/badge.jsx
0.00% <0.00%> (ø)
0.00 <0.00> (?)

web-ui/src/client/app/containers/editor.jsx
41.66% <ø> (ø)
0.00 <0.00> (ø)

web-ui/src/client/app/containers/app.jsx
90.00% <83.33%> (-10.00%)
0.00 <0.00> (ø)

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 7b89cbe...8fc0606. Read the comment docs.