Artifacts in classification example in 1.70?

This was reported over email - the classification example (https://sandcastle.cesium.com/index.html?src=3D Tiles Photogrammetry Classification.html) has these artifacts, almost as if the the classification tileset is being clipped too early by the near plane, only on mobile (Android or iOS).
I put together an example on Glitch to make it easier to test on mobile (you can fork it and change the CesiumJS include to 1.69 to see that it works there, and the artifacts are only present in 1.70.
https://glitch.com/edit/#!/classification-cesium-error?path=index.html%3A5%3A68
1.70

1.69

I don't see an obvious place to start looking as the cause of this break in the CHANGES for 1.70, any advice @lilleyse ?

Either https://github.com/CesiumGS/cesium/pull/8854 or https://github.com/CesiumGS/cesium/pull/8870

Git bisect confirms this is the commit that introduced this issue: https://github.com/CesiumGS/cesium/pull/8854/commits/2da52de16d6a3022278a328d8242f17e10f28f02

Marking as priority next release since it's a regression that's breaking some people's applications.

If we figure out why this regression happened, it might help us understand non-3D Tiles classification bugs on mobile. Last time I looked I didn't have any leads, but I'll look some more soon.

Haven't had a chance to look into this enough, so it should be pushed to the next release (again). It's looking like a multi-frustum problem though.

git bisect points to https://github.com/CesiumGS/cesium/commit/2da52de16d6a3022278a328d8242f17e10f28f02
It's a multi-frustum problem that can be triggered by disabling log depth.
Local sandcastle


I ran into a problem after switching to a new version1.0.0-rc.0 in my project

Steps to Reproduce (for bugs)

I switched to the new version v1.0.0-rc.0
changed all the way to new. example: import { withStyles } from "@material-ui/core/styles";
and my project started to give an error

Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
installed using yarn install@material-ui/core
old version deleted
Your Environment

Tech
Version

Material-UI
1.0.0-rc.0

React
16.3.2

browser
Chrome v66.0.3359.139

{
  "name": "react-chat",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@material-ui/core": "^1.0.0-rc.0",
    "@material-ui/icons": "^1.0.0-rc.0",
    "classnames": "^2.2.5",
    "material-ui": "^1.0.0-beta.47",
    "react": "^16.3.2",
    "react-dom": "^16.3.2",
    "react-router-dom": "^4.2.2",
    "react-scripts": "1.1.4",
    "typeface-roboto": "^0.0.54"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

@vladseverin You might have forgotten some import. Don't miss our codemod to fix all the occurrences: https://github.com/mui-org/material-ui/blob/master/packages/material-ui-codemod/README.md#import-path.

@oliviertassinari Instead of saying warning<EMAIL_ADDRESS>You can now upgrade to @material-ui/core, how about instead linking to that README? Would have saved me a bunch of time and effort.

@octavioamu Also, the README instructions are for .js and I use .ts and .tsx. They also do not properly escape the @ in the shell, so the path isn't found.

@octavioamu Yep, as I suspected. No typescript support in jscodemod.

@oliviertassinari Thanks for the link, solved the problem by automatically changing paths


Update pl translation.json

Translation into Polish, because I saw that it was missing.

merged in #654


Icon issue Cannot read properties of null (reading 'insertBefore')

There seems to be an issue with the icons when navigating from a page that's a couple of layers deep to a page on the first layer, both in dev an production. In the browser console the following error is generated:
TypeError: Cannot read properties of null (reading 'insertBefore')

See the following sample repo: https://github.com/Knordy/nuxt-icon-issue, using the latest version 1.5.6
The steps to reproduce are:

From Home click on A3
From A3 click on A4
From A4 click on B

Removing the icons does not trigger this error.
Removing page A, A1 and A2, but keeping the depth of the pages does not trigger the error.
Following various other navigation paths does not trigger the error: from Home -> A1 -> A4 -> B for example.

Thanks a lot for the great reproduction! I think this is an upstream bug with Vue's Suspense + Vue Router - this is also caused by NuxtIcon being an async component. I will see how I can workaround this before it get fixed in Vue.

cbb24cd4384afbe843ee1c9b9120dfea7203a94b should fix it

@antfu Thank you for the update. We will verify if this also fixes the issue in our solution.


Training log

Hi, great work.
Can you provide the training logs as well as the checkpoints for classic cv training?

We will as we did in TorchSSL, please wait.


I18n (Work In Progress)

What is the Purpose?
Resolve issue #432
What was the approach?
Mainly this blog post: using Django i18n built-in support and providing translations in .po files
French translations are available. To test them change the variable LANGUAGE_CODE to fr.
German files are also provided under templates/locale.
Are there any concerns to addressed further before or after merging this PR?
None.
This PR is still WIP. Just thought it was be cleaner to gradually merge it into the dev branch because it will bring a lot of changes.
Issue(s) affected?
#432

Codecov Report

Merging #442 into dev will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #442   +/-   ##
=======================================
  Coverage   50.28%   50.28%
=======================================
  Files          98       98
  Lines        8304     8304
=======================================
  Hits         4176     4176
  Misses       4128     4128

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 bade5d2...d67827c. Read the comment docs.

Tagged and translated templates:

All the top-level templates, except pop_up.html, release.html
All templates under templates/registration except activate_email.html and the .txt files
templates/indicators/collecteddata_list.html
templates/indicators/disaggregation_report.html
templates/indicators/indicator_form_tab_ui.html
templates/indicators/indicator_form.html
templates/indicators/indicator_list
templates/indicators/program_indicators_table.html

As to testing the i18n, I just manually switch the setting LANGUAGE_CODE to fr-FR.
Later, this should be deduced smartly from the user.
To generate locale files for the templates: cd templates && django-admin makemessages -l fr

Looks good, I see there is a conflict with the docker-compose.yaml file. I'd like to ask if @Kimaiyo077 @mikael19 can help to review this more thoroughly. Also @nasirhjafri if you have time that would be great too! Thanks!

I think this is a very good start. Here is how I see the steps required to complete this feature:
1- Start working with the English language. Convert all available text into translatable variables. (This is what is currently being done)
2- Add other languages that we wish to support in the settings. Set for localization:- Generate the .po files which translators will use.
3- Add a language field to the user(could be the Abstract base user or ActivityUser) where he will be able to select languages configured in (2) above.
4- Pass the User preferred language to the templates for the required translation to occur. There are some packages that could help with that; django user language middleware, django localeurl, etc
5- Establish the language priority below:

user preferred language
browser language
default language in settings.

I think this is too big a task for just one issue. I suggest that, after he is done with creating the .po files for English language, we can open another issue for the next steps; otherwise, this PR will be huge.

@mikael19 @Kimaiyo077 can you kindly help to resolve the conflicts and we are ready to merge the PR


python3 compatible DiViMe

List of commands

[X] tools/test.sh
[x] tools/noisemes_sad.sh
[x] tools/noisemes_full.sh
[x] tools/opensmile_sad.sh
[x] tools/tocombo_sad.sh
[ ] tools/diartk.sh
[x] tools/yunitate.sh
[ ] tools/yuniSeg.sh
[ ] tools/eval.sh

List of issues

[x] model encoding problem (Should update all model/pickled files with unicode encoding)
-  changed dill to python pickle to use encoding parameter when loading pickle files.
[x] Theano cython problem

/opt/anaconda/envs/divime/lib/python3.6/site-packages/theano/scan_module/scan_perform_ext.py:76: UserWarning: The file scan_perform.c is not available. This donot happen normally. You are probably in a strangesetup. This mean Theano can not use the cython code for scan. If youwant to remove this warning, use the Theano flag'cxx=' (set to an empty string) to disable all ccode generation.

Installing theano with pip instead of conda solves theano-cython problem

closed as of #77


Add configuration of key-pair for AWS EC2 in provisioner

Tell us about your request
Configure key-pair for AWS EC2 in provisioner
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
If we use Bottlerocket AMI Family we must have key-pair to access the EC2 instance under ec2-user user, SSM agent in this case is just able to enable admin access only
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

I wonder if the Bottlerocket folks would be able to open up admin access via SSM.

@ellistarn Nope, reference to https://aws.amazon.com/bottlerocket/faqs/

How do I debug issues with Bottlerocket?

You can run an “admin container” using Bottlerocket's API (invoked via user data or AWS Systems Manager) and then log in with SSH for advanced debugging and troubleshooting with elevated privilages. AWS provides the admin container that allows you to install and use debugging tools like sosreport, traceroute, strace, tcpdump. The act of logging into an individual Bottlerocket instance is intended to be an infrequent operation for advanced debugging and troubleshooting.

@bwagner5 I don't know why karpanter does no support add ssh key-pair to configuration, is there any background reason?

As I said in previouse comment, using SSM with bottolerocket just support to enable admin access, that's all, we are not able to switch user ther
Using EC2 Instance Connect requires public IPv4 address which is most avoided in EKS cluster nodes.

@bwagner5 Security aspect is belong to users, they should aware the risk to decide attach SSH keys to the EC2 not the tool to block an option, I think
Thanks for your help to show me enter-admin-container but it does not help much since we're still in chroot not full control at all
[root@admin]# systemctl status kubelet
Running in chroot, ignoring request.

@vumdao you need to drop into the actual root filesystem shell by running sudo sheltie
$ enter-admin-container
$ sudo sheltie
$ systemctl status kubelet
● kubelet.service - Kubelet
     Loaded: loaded (/x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/kubelet.service.d
             └─exec-start.conf
     Active: active (running) since Mon 2022-04-11 18:38:35 UTC; 6min ago
       Docs: https://github.com/kubernetes/kubernetes
   Main PID: 6176 (kubelet)
      Tasks: 54 (limit: 629145)
     Memory: 258.1M
        CPU: 37.266s
     CGroup: /runtime.slice/kubelet.service
...

Hi @ellistarn @bwagner5 @vumdao,
I just get a chance to read through your questions/responses.
I am agree it's more secure and a good way to use SSM session to connect to a node if it is necessary.
How you do think my arguments below ?

Karpenter supports only AWS for the moment, but according to the documentation, it seems that we want to support also the other cloud providers if people contributes on it. Here, with your suggestion, it is more a provider-specific option. It is not extensible or flexible for the futur multi-cloud supporting purpose.
As a product, we'd better leave the choices to the users, instead of making the decision for them. At least we provide the option for them to add the SSH key pair. But suggest them to not do that if not really necessary. If they do that, they should be aware of the danger and should take their responsibility for the security of their own infrastructure.
As an admin, I find it also fast and convenient to use command line to SSH into different nodes within 2 seconds. While, with SSM session, it may take longer time and should do more clicks. In addition, with SSH, we could take advantage of our own featured terminals.

Thanks.

Yes, please provide feature to add key-pair. Like us some organisations have LDAP based authentications for users. So it should be an option to add keys.

We've documented a method to configure ssh-keys here: https://karpenter.sh/v0.17.0/faq/#can-i-add-ssh-keys-to-a-provisioner

We've documented a method to configure ssh-keys here: https://karpenter.sh/v0.17.0/faq/#can-i-add-ssh-keys-to-a-provisioner

That page no longer exists when I click the link.  Did it move? (and is it still relevant?)

Here's a permalink: https://karpenter.sh/docs/faq/#can-i-add-ssh-keys-to-a-provisioner

@ellistarn I am currently migrating from cluster-autoscaler (where I specified an AWS key pair in the launch template to be able to SSH into my nodes with an SSH key provisioned in AWS by infra-as-code) to karpenter and I just found out this thread.
The documentation you refer to is helping to put a key directly in the user-data but it is not helping in specifying an AWS key-pair as we can do when launching an EC2 instance in the console or like I said above in a launch template.
In our case, our cluster is not an EKS one (we deployed it on EC2 instances with specific user-data that contains the kubeadm logic) and we use a custom AMI (based on a CIS AMI from AWS marketplace for security reason).
We do not want to use ec2-instance-connect for now.
In addition to benefit from the great features of karpenter, we would like to keep the same user experience as before.
And I may add that I quite agree with @vumdao  : karpenter is an autoscaling tool, even if it can come with best practices by default, decision about security details should belong to the users in the end, and karpenter should allow all basic features provided by EC2 like attaching an SSH key pair.
Is it possible to reopen this issue please ?

+1 for @yogeek
up until now i've been using Provisioner and refer a aws launch template were i could set aws key pair name.
while trying to migrate to 0.32.x version, found out its no longer possible (had to debug why nodes will not connect to cluster),
connecting to an instance is a very rare event for me, but when its needed something really bad probably happened, please respect AWS EC2 api and let us decide how to connect to instances (personally i cannot even use SSM due to SSM not configured in the custom enterprise AMI i use) for now its a big blocker for upgrading karpenter, and a potential product drop if not added.

Are you able to use ec2-instance-connect instead of SSM for SSH access? https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-eic.html

Related to https://github.com/aws/karpenter/issues/2432

Are you able to use ec2-instance-connect instead of SSM for SSH access? https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-eic.html

had to extend our AMI to be able to use SSM (didn't wanted to deal with VPC endpoints to get the ec2-instance-connent working)
not related to the issue, but if anyone facing nodes not connecting to cluster api, check your aws-auth configmap 🤦♂
was able to continue with the 0.32.x upgrade, but i still think that SSH should stay an option.

Can we reopen this?
While i can use EC2 Instance Connect, I have clusters were I don't manage (and i don't want to manage) an additional endpoint.
The userdata option doesn't seem to work properly and it's overly complicated, since this should be an AWS basic feature.

any chance we can reopen this issue?
I agree with the benefits of promoting SSM/EC2 instance connect. If karpenter EC2NodeClass can provide better parity with launch template, it would reduce the friction for more people to adopt karpenter.
Note that SSM / EC2 instance connect are both vendor-specific and this may be less preferred compared to SSH.

How to give keypair configuration in karpenter EC2NodeClass ?
So that I can ssh in to the ec2's

@vumdao EC2 Instance Connect is able to SSH to instances with a private IP address: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html#:~:text=private IP addresses
We have avoided adding the key-pair to the provisioner to limit long-term SSH keys being placed on instances. We think that using SSM or EC2 Instance Connect for SSH access is a more secure way of accessing nodes.
You can gain root access to the bottlerocket host through the admin container. There is no direct way to SSH to a bottlerocket host without the admin container.
Here are the steps:

Login to bottlerocket w/ ssm aws ssm start-session --instance-id <instance-id>
Once connected, on the prompt, type: enter-admin-container
Once inside the admin container, you can execute sudo sheltie

From the admin container's MOTD:
         Welcome to Bottlerocket's admin container!
    ╱╲
   ╱┄┄╲   This container provides access to the Bottlerocket host
   │▗▖│   filesystems (see /.bottlerocket/rootfs) and contains common
  ╱│  │╲  tools for inspection and troubleshooting.  It is based on
  │╰╮╭╯│  Amazon Linux 2, and most things are in the same places you
    ╹╹    would find them on an AL2 host.

To permit more intrusive troubleshooting, including actions that mutate the
running state of the Bottlerocket host, we provide a tool called "sheltie"
(`sudo sheltie`).  When run, this tool drops you into a root shell in the
Bottlerocket host's root filesystem.

Hope this helps!

IMO, this is not a reasonable choice. People should be able choose whether to configure a key pair.
In many situations, we need to access the host. Any solution that depends on a running container assumes that the kubelet is up and running. However, if there is any issue preventing a node from joining a cluster, these solutions become useless.
The other solutions mentioned are vendor-specific and require a certain amount of configuration.
SSH has been a standard for a decade. Any infrastructure provider provides an easy way to configure an SSH-key pair. AWS, in this case, allows it very easily.
It makes no sense to me, to not allow people to configure a key pair either at the node pool or node class level.


VS Code installed via Snap does not appear in flutter doctor

Flutter doctor -v
when i run flutter on Linux and vs code was installed through snap, it doesn't appear in Log.

Proposal
Consider also VS Code Snap in linux

it doesn't appear in Log.

Do you mean in flutter doctor? Please include the output of flutter doctor -v. Additional, if you include the location where snap installed vs code on linux that would be helpful too

when i run : flutter doctor -v

i am using ubuntu 20.04

---- output ->
[✓] Flutter (Channel stable, v1.12.13+hotfix.9, on Linux, locale en_US.UTF-8)
    • Flutter version 1.12.13+hotfix.9 at /home/jeanluckabulu/flutter
    • Framework revision f139b11009 (10 days ago), 2020-03-30 13:57:30 -0700
    • Engine revision af51afceb8
    • Dart version 2.7.2

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /home/jeanluckabulu/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /opt/android-studio-ide/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Android Studio (version 3.5)
    • Android Studio at /opt/android-studio-ide/android-studio
    • Flutter plugin version 44.0.1
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] Connected device (1 available)
    • SM G935F • 6911789f • android-arm64 • Android 8.0.0 (API 26)

• No issues found!

This command is runned in vs code terminal
VS CODE INSTALLED FOLDERS
when you use apt : vs code can be found in /usr/share/ folder ( /usr/share/code)
when you use snap : vs code can be found in /snap/ folder ( /snap/code)

Thanks!

I can confirm VS Code is still not detected when installed via Snap
When installing from apt

flutter doctor -v
[✓] Flutter (Channel master, 2.1.0-13.0.pre.346, on Linux, locale en_IN)
    • Flutter version 2.1.0-13.0.pre.346 at /home/taha/Code/flutter_master
    • Framework revision 8158b478d7 (7 hours ago), 2021-03-31 13:29:03 +0800
    • Engine revision dbcbf69a57
    • Dart version 2.13.0 (build 2.13.0-175.0.dev)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/taha/Code/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /home/taha/Code/SDK
    • Java binary at: /home/taha/Code/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.
[✓] Chrome - develop for the web
    • Chrome at google-chrome
[✓] Linux toolchain - develop for Linux desktop
    • clang version 10.0.0-4ubuntu1
    • cmake version 3.16.3
    • ninja version 1.10.0
    • pkg-config version 0.29.1
[✓] Android Studio (version 4.1)
    • Android Studio at /home/taha/Code/android-studio
    • Flutter plugin version 54.1.1
    • Dart plugin version 201.9335
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
[✓] VS Code (version 1.54.3)
    • VS Code at /usr/share/code
    • Flutter extension version 3.20.0
[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Linux
    • Chrome (web)    • chrome • web-javascript • Google Chrome 89.0.4389.90
• No issues found!

When installing from snap

flutter doctor -v
[✓] Flutter (Channel stable, 2.0.3, on Linux, locale en_IN)
    • Flutter version 2.0.3 at /home/taha/Code/flutter_stable
    • Framework revision 4d7946a68d (13 days ago), 2021-03-18 17:24:33 -0700
    • Engine revision 3459eb2436
    • Dart version 2.12.2
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/taha/Code/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /home/taha/Code/SDK
    • Java binary at: /home/taha/Code/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.
[✓] Chrome - develop for the web
    • Chrome at google-chrome
[✓] Linux toolchain - develop for Linux desktop
    • clang version 10.0.0-4ubuntu1
    • cmake version 3.16.3
    • ninja version 1.10.0
    • pkg-config version 0.29.1
[!] Android Studio (not installed)
    • Android Studio not found; download from
      https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup
      for detailed instructions).
[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Linux
    • Chrome (web)    • chrome • web-javascript • Google Chrome 89.0.4389.90
! Doctor found issues in 1 category.
taha@taha-Lenovo-ideapad-510S-14IKB:~$

I have the same issue...!!

CC @MarcusTomlinson
Is this an issue from Flutter or flutter-snap?

CC @MarcusTomlinson
Is this an issue from Flutter or flutter-snap?

It doesn't appear to be flutter-snap related. In your test you ran flutter doctor -v from a manual install and saw the issue. This is probably Flutter not looking in snap paths.

@MarcusTomlinson
I wrote it wrong, I meant it do you think it is an issue with vscode snap or flutter.
It makes that Flutter mot looking for snap paths


Is it possible to add multiple heatpumps in this integration

I have to integrate morte than one ?
Ist it possible, and when how.
I did not read something about.
This integration is awsome helpfull, so i want to integrate more

soory doubled entry i saw now this question is mentioned before

Duplicate #16


False positives for prefer-for-of rule

Bug Report
There are a couple of cases where the prefer-for-of rule produces linter errors on code can not be trivially converted to a for-of loop. In particular:

Step values != 1
Start of iteration != 0
Reverse iteration

Additionally, there are a few other cases where errors aren't reported, but possibly should, such as: <= arr.length - 1 instead of < arr.length.
I have mixed feelings about whether or not reverse iteration should trigger this error or not. Sometimes the array can just be reversed before iteration, other times you might want to clone the array first before reversing.
I guess in any of these cases, you could write helper functions to minimize the places where you need to opt-out of this rule, but at that point you aren't really preferring for-of so much as you are not preferring bare for-loops.
/* tslint:disable:prefer-for-of */
forEachWithStep<T>(array: Array<T>, step: number, func: (T) => void) {
    for (let i = 0; i < array.length; i += step) {
        func(array[i]);
    }
}

partialForEach<T>(array: Array<T>, start: number, end: number, func: (T) => void) {
    for (let i = start; i < end; i++) {
        func(array[i]);
    }
}

reverseForEach<T>(array: Array<T>, func: (T) => void) {
    for (let i = array.length; i>= 0; i--) {
        func(array[i]);
    }
}
/* tslint:enable:prefer-for-of */

TSLint version: 4.0.1
TypeScript version: 2.1.1
Running TSLint via: Node.js API

TypeScript code being linted
declare var arr: number[];
declare var step: number;

// trivial #1: array iteration [0,length)
for (let i = 0; i < arr.length; i++) {
   console.log(arr[i]);
}

// trivial #2: effectively the same as trivial #1, but not caught
for (let i = 0; i <= arr.length - 1; i++) {
   console.log(arr[i]);
}

// trivial #3: i++, ++i, and i += 1 should all be considered
for (let i = 0; i < arr.length; i += 1) {
   console.log(arr[i]);
}

/****************************************************************/

// non-trivial #1: array iteration with step size not known to be 1
for (let i = 0; i < arr.length; i += step) {
   console.log(arr[i]);
}

// non-trivial #2: non-zero start of iteration
for (let i = 1; i < arr.length; i++) {
   console.log(arr[i]);
}

// non-trivial #3: reverse iteration...
for (let i = arr.length; i >= 0; i--) {
   console.log(arr[i]);
}

with tslint.json configuration:
{
    "rules": {
        "prefer-for-of": true
    }
}

Actual behavior
Trivial Loops:
test.ts[5, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration
test.ts[15, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration

Non-Trivial Loops:
test.ts[22, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration
test.ts[27, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration
test.ts[32, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration

Expected behavior
The first 3 trivial loops should be reported as errors, the last three loops should not trigger the error.
Trivial Loops:
test.ts[5, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration
test.ts[10, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration
test.ts[15, 1]: Expected a 'for-of' loop instead of a 'for' loop with this simple iteration

Non-Trivial Loops:
[no errors]

I just noticed that #1758 was merged while I was writing up the bug report. It looks like that should cover most of these cases except possibly Trivial #2.

the PR does not cover Trival #2, but I don't think that is very common

closed as duplicate of #1753


Database Tables for Annotations

Kind of what I'm thinking is like

user_id
created_time
modified_time
reference_type (table)
reference_id
comment
title (32 character limit or something)

That way we can associate comments with just about anything in asset management.

What do you think reference_id contains?  It seems like there would be a references table, but I'm fuzzy on what references really needs to be.

I'm not sure the best way to do it but it would be nice to have the ability to annotate just about anything. For delivery 3 it just has to be a stream but in the long run, if it's technically easy, I was thinking we could have a column that would identify the table that it relates to and the reference_id be the id column of the referenced table.
so like

id
created_time
modified_time
reference_type
reference_id
title
comment

12
...
...
streams
1203
Instrument Removed
We removed the instrument from the bathtup to remove fouling

13
...
...
instrument_deploymetns
12
Initial Deployment
First time we've deployed this instrument

will do...making it so now for discussion later today


WebSocket Ping Interval Raises Bad state: Cannot add event after closing

WebSocket Ping Interval Raises Bad state: Cannot add event after closing
Source:
    var url = 'wss://stream.binance.com:9443/ws/!miniTicker@arr';
    _webSocket = await WebSocket.connect(url).catchError((e) {
      print('Failed to connect to $url because $e retry in 5 seconds');
    });
    _webSocket?.pingInterval = Duration(minutes: 2);
    _webSocket?.listen((data){
        print(data);
     });

Trace Logs:
#0      _StreamController.add (dart:async/stream_controller.dart:585:24)
#1      _WebSocketConsumer.add (dart:_http/websocket_impl.dart:953:17)
#2      new _WebSocketImpl._fromSocket.<anonymous closure> (dart:_http/websocket_impl.dart:1133:38)
#3      _rootRunUnary (dart:async/zone.dart:1132:38)
#4      _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#5      _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#6      _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
#7      _BufferingStreamSubscription._add (dart:async/stream_impl.dart:263:7)
#8      _SinkTransformerStreamSubscription._add (dart:async/stream_transformers.dart:68:11)
#9      _EventSinkWrapper.add (dart:async/stream_transformers.dart:15:11)
#10     _WebSocketProtocolTransformer._startPayload (dart:_http/websocket_impl.dart:310:24)
#11     _WebSocketProtocolTransformer._lengthDone (dart:_http/websocket_impl.dart:290:7)
#12     _WebSocketProtocolTransformer.add (dart:_http/websocket_impl.dart:194:13)
#13     _SinkTransformerStreamSubscription._handleData (dart:async/stream_transformers.dart:120:24)

This tracker is for issues related to:

Dart core libraries ("dart:async", "dart:io", etc.)

dart --version
Dart VM version: 2.2.0 (Tue Feb 26 15:04:32 2019 +0100) on "macos_x64"

I didn't reproduce it locally. It looks like websocket received a ping and tries to response it with a pong but it is closed at that time. Is it easy to reproduce?

The same issue: #37417


Clarification : New release create with PAT user but it should be originally build create user

For which extension would you like to add a feature request?
Question
I have a release pipeline called 'Parent Release' and 'Child Release.' I use an extension in the 'Parent Release' to trigger a new 'Child Release.' The problem is that the user created in the 'Child Release' appears as the PAT (Personal Access Token) created user instead of the 'Parent Release' created user. Is there any way to fix this?

Hi @LilanSilva not completely sure what you mean. Important is that the connection is made from the parent pipeline to the child one. There are no real specific permissions.

My requirement is that when a developer commits changes to the master branch, a release pipeline called “Parent release pipeline” is triggered using the build from that commit. This release pipeline includes a "Trigger Azure DevOps Pipeline" step to trigger another release pipeline called “Child release pipeline” based on the build artifacts. To achieve this, I used the "Trigger Azure DevOps Pipeline" extention with a Personal Access Token (PAT). However, when I trigger a new release (“Child release”) pipeline using the PAT, the PAT is treated as the user creating the new release, causing an issue. New release (“Child release”) create user should be originally build trigge user.

Oke, so the user that triggered the parent pipeline should also be the one that triggers the child pipeline is that correct?


Can't exec on pods

Describe the bug
Lens no longer connects to a shell on pods on my setup. Maybe related to the proxy.
We have to connect to our clusters via a jumpbox so I open a socks proxy with ssh then use tinyproxy to act as a http -> socks proxy middle man. This works fine for the normal kubectl on my system with the HTTP_PROXY var set for the tinypoxy port but doesn't seem to work in Lens. If unset KUBECONFIG in Lens it work again. I'm on 3.6.4. I see there was a note in prior releases about the proxy not working in some cases but it wasn't in this one so I'm guessing it was resolved.
To Reproduce
Steps to reproduce the behavior:

Use a ssh jumpbox to reach k8s via a socks proxy ssh -D 12345 <jumpbox>
Set up a proxy server to act as HTTP to socks proxy (relevant tinyproxy config below)

Port 8118
Listen <IP_ADDRESS>
upstream socks5 <IP_ADDRESS>:12345

Set up shell rc file to use proxy export HTTP_PROXY=http://localhost:8118
Open Lens and navigate to cluster with HTTP Proxy set in config http://localhost:8118
Look at pods, see them as expected.
Navigate to pod and click icon for Pod shell
Wait for timeout error: unable to upgrade connection: error dialing backend: dial tcp <ip>: i/o timeout
Copy and paste command into personal shell and see it work.

Expected behavior
Connect to pod shell
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

Lens Version: 3.6.4
OS: OSX
brew cask installed but updated from within app
In case it helps, tinyproxy also comes from brew tinyproxy: stable 1.10.0 (bottled)

Logs:
When you run the application executable from command line you will see some logging output. Please paste them here:
❯ exec kubectl exec -i -t -n <namespace> <pod> -c <container name> "--" sh -c "clear; (bash || ash || sh)"
error: unable to upgrade connection: error dialing backend: dial tcp <IP>: i/o timeout
Terminal will auto-close in 15 seconds ...

Kubeconfig:
Quite often the problems are caused by malformed kubeconfig which the application tries to load. Please share your kubeconfig, remember to remove any secret and sensitive information.
apiVersion: v1
kind: Config
preferences: {}
current-context: <redacted>
clusters:
  - name: <redacted>
    cluster:
      server: 'http://<IP_ADDRESS>:52181/<UUID>'
contexts:
  - name: <redacted>
    context:
      cluster: <redacted>
      user: proxy
users:
  - name: proxy
    user: {}

Additional context
Add any other context about the problem here.

I feel like I should mention that I noticed it not working before this release but I don't know what release it started on. I didn't get around to digging into the problem until now. Happy to test some things though.

Please could you test with 3.6.5-rc.1? There's one fix that is targeting especially to fix kubectl exec requests, but your issue looks a bit different, so not sure is it fixing also this.

No dice. I grabbed a tcpdump so I'll review and see if I can figure out what's going on.

Speaking of, I don't know of a way to dump master secret from kubectl or otherwise get an unencrypted traffic log from it. If you know off hand that would save me some heart ache.

This is most likely a bug with 3.6.x series (including 3.6.5-rc.1). Lens should not pass HTTP_PROXY envs to Lens terminal because all traffic needs to go through Lens itself.

3.6.5 still doesn't work for me. Should I open another? I'm going to try to learn some more node side JS/TS and see if I can track down my own problem.

Same issue witnessed while setting HTTPS_PROXY=socks5://localhost:8888 on version 4.0.0.

kubectl exec to pods from Lens lead  to
error: unable to upgrade connection: error dialing backend: dial tcp <IP_ADDRESS>:6443: i/o timeout
connection to nodes also fails
while other kubectl commands are successful.

Note that I am also setting the proxy in kubeconfig with the cluster section field proxy-url now available for it (cf: https://github.com/kubernetes/kubernetes/pull/81443/commits)

Pod shell error with proxy http://localhost:8005:
~ exec kubectl exec -i -t -n clc auth-center-5d54b96bf5-9p7bw -c auth-center "--" sh -c "clear; (bash || ash || sh)"
error: unable to upgrade connection: error dialing backend: dial tcp <IP_ADDRESS>:6443: i/o timeout
Terminal will auto-close in 15 seconds ...

Lens version:
Lens: 4.0.8
Electron: 9.3.5
Chrome: 83.0.4103.122
Node: 12.14.1
Copyright 2020 Mirantis, Inc.


Some collective details are not updated when switching from user menu

Describe the bug
When switching collectives from the user menu some details are not updated properly. This does not happen when switching collectives by clicking on other links (like from cards).
To Reproduce
Steps to reproduce the behavior:

Login
Go to a collective page
Open your user menu, select another collective
See error

Expected behavior
All info should be updated.
Screenshots

Desktop (please complete the following information):

Ubuntu
Firefox

Additional context
Tested on staging / prod

I fixed something like that long time ago. It was some properties that were copied on instantiation and never updated in the component.

@znarf The reason may be similar here. I think we should set a high priority on this, we're not sure about the consequences it may have, maybe a user could en up doing an action on another collective than what he intended.

I have not be able to reproduce this in local, staging nor production. I may have encountered a local cache issue here.


Jaeger's LFX Mentorship - 2024 Term 01, March - May

I want to try a different approach in this round. Rather than have small independent projects as we did previously (#4457), I would rather have 2-3 mentees working collectively on one project. This will better approximate their future industry experience and will allow us to tackle more interesting projects.
For the spring term, this will be Jaeger-v2 project. For details and motivation of the project please refer to the main ticket

https://github.com/jaegertracing/jaeger/issues/4843

Sub-projects for mentorship
While I don't have strong preference which part of jaeger-v2 overall roadmap will be completed during the mentorship, the LFX process requires to create three separate projects, so my proposal is to tackle these areas:
P1: Build out full support in jaeger-v2 for all storage backends supported by jaeger-v1

Currently only memory storage is wired in v2, we need to add Elasticsearch, Opensearch, Cassandra, Badger
Extend existing integration tests to cover jaeger-v2

P2: Achieve observability parity between v1 and v2 (metrics, logs, traces)

Currently jaeger-v2 components are initialized without observability clients
We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components
The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes

P3: Support adaptive sampling

Jaeger-v1 collector can serve sampling configuration to SDKs, and allows either static configuration (with hot reload) or adaptive sampling that continuously re-calculates the desired sampling probabilities.
We need to enable all these capabilities in jaeger-v2
Docs: https://www.jaegertracing.io/docs/1.52/sampling/#remote-sampling

Application process

For details about LFX mentorship & the application process, see https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship.
Proposal required: since we had a high number of applicants in the previous rounds, we strongly recommend submitting a proposal as part of your application. It helps us select mentees who are the best match for the project. Please see https://www.jaegertracing.io/mentorship-for-mentees/ regarding proposal details.

LFX website does not allow uploading additional documents, so include the proposal in the Cover Letter.

For deadlines, see https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2024/01-Mar-May

Mentee applications open between Monday Jan 29 - Tues Feb 13, 5:00 PM PDT

Direct link to applying: https://mentorship.lfx.linuxfoundation.org/participate/mentee

Getting Started
While the timelines in LFX programs are not very long, we recommend trying to get your hand dirty with small contributions to the project before applying.
Reach out on Slack with other questions.

The prospect of working collectively on a comprehensive project like Jaeger-v2 is truly exciting, and I am keen on contributing my skills and enthusiasm to its success. The outlined sub-projects align perfectly with my interests, and I believe they present a great opportunity for learning, growth and industrial exposure.
I am looking forward to the possibility of contributing to the Jaeger-v2 project and learning from the experience 🚀.

@Wise-Wizard glad to hear. I wish LFX was more flexible in the setup - I had to define 3 projects and when applying you have to choose which one to apply, even though, as I mentioned, I don't particularly care if we work on these specific projects or just pick any other tasks from the V2 roadmap.

I am interested in working on this project too.

@Wise-Wizard glad to hear. I wish LFX was more flexible in the setup - I had to define 3 projects and when applying you have to choose which one to apply, even though, as I mentioned, I don't particularly care if we work on these specific projects or just pick any other tasks from the V2 roadmap.

Yes understandable, I will also study in depth about the projects and apply considerably, to learn and contribute more efficiently for the V2 project's success. Meanwhile, I will look into remaining issues that are leftover!

I am writing to express my excitement and gratitude for the upcoming mentorship during the 2024 Term 01. The prospect of being guided by someone of your caliber is truly inspiring, and I look forward to the growth and learning this experience will undoubtedly bring.
As we embark on this mentorship journey, I am eager to gain insights from your expertise and delve into the hands-on projects that will shape my understanding of the field. The anticipation of collaborating with like-minded peers and the expectation of a supportive learning environment have already fueled my enthusiasm.
I am confident that your mentorship will provide not only technical knowledge but also invaluable insights into the broader aspects of the industry. I appreciate the opportunity and am ready to make the most of this learning experience.
Thank you in advance for your guidance, and I look forward to the exciting and enriching journey ahead.

Has the spring term been filled yet？

I think I may have missed this opportunity, term2 to participate again

@Axkea Term 1 has not been filled yet. Actually it's not even opened yet...
Application will open soon (see the issue description for details). But it doesn't hurt to start preparing your application now. That will give you a fair advantage.

@Axkea Term 1 (Mar-May) has not been filled yet. Actually it's not even opened yet...
Application will open soon (see the issue description for details). But it doesn't hurt to start preparing your application now. That will give you a fair advantage.

Thank you for your answer, I mistakenly thought that the deadline for personal proposals was 24 January 2024

Thank you for your answer, I mistakenly thought that the deadline for personal proposals was 24 January 2024

No worries this usually causes confusion... The first deadline is actually for mentors proposing project ideas to CNCF. After that will be mentee's application round (where you submit your proposal).

I think this collaborative approach is awesome.

@yurishkuro, I am interested into it, and would like to get into further research to contribute to it.

By going thoroughly, with the ideas Creating storage backends for V2 with opensearch, elasticsearch and others is likely captivating me more. I would like to discuss it. How do I reach out to the members?

you can ask here or on Slack (https://www.jaegertracing.io/get-in-touch/)

Hey, project 2 i.e. "Achieve observability parity between v1 and v2 (metrics, logs, traces)" sounds interesting to me! I'll reach out on the slack channel & learn more about what needs to be done!
Thanks

adding support for Cassandra


Fix data2cypher API url config.

The old config would cause requesting to a wrong URL.

It seems this is dup with https://github.com/neo4j/NaLLM/pull/76. Closed.


Review logging functionality

This is kind of open-ended. We need to consider a few things.

How extensive of logging support do we need?

Structured/Text?
Probably want to do as little as possible, so maybe structured plus a pluggable log interface. The default (and only builtin) should probably just print to stdout/stderr

Need to normalize and localize? messages. Basically, resources should output messages in a standard format. Right now it emits custom errors, errors, or strings, etc.

We should probably output structured logging, and have a default text output for simplicity. For example, it'd be nice to be able to filter logging for only mutated resources.

Also, the current logging uses some unicode chars that aren't available in all terminals. Maybe see how something like https://github.com/iarna/gauge/ handles that.


[CT-677] [Bug] Downstream models do not run correctly after NetworkX 2.8.1

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Any 1.0.x version of dbt installed after NetworkX 2.8.1 was released does not correctly run downstream models when using selection syntax.  For some reason this does not seem to effect 1.1
Expected Behavior
All downstream models are run
Steps To Reproduce
Install dbt- @ v1.0.x
Create a project with a model_foo and downstream model_bar
Run dbt with selection dbt run --select +model_foo+
Observe that only model_foo is run
Relevant log output
No response
Environment
- OS: MacOS
- Python: 3.10
- dbt: 1.0.6

What database are you using dbt with?
postgres
Additional Context
No response

https://github.com/networkx/networkx/milestone/21?closed=1 -- looks like 2.8.2 of networkx is incoming...

2.8.1 broke, but 2.8.2 did not fix whatever is now wrong with the graph stuff and newtorkx.

After quite a few hours of investigation, this is proving a VERY difficult bug to track down.
Here's a synopsis of the work so far.
We're doing this wrong
The issue can be traced back to our use of nx.single_source_shortest_path_length in dbt-core <1.1.x here and here.
Specifically, it's used to return a list of a given node's descendants, and by reversing the graph first, it's ancestors.  However, that isn't really what that function is supposed to do!  Using the DAG-specific nx.ancestors and nx.descendants works correctly in all versions and should have probably been what we did in the first place.  The only downside to this approach is that nx.desc / nx.ances don't offer a max depth option but it's a simple enough thing to implement.
There's still a bug, even when we do it the "right way"
In researching this it was discovered that doing any kind of iteration over self.graph immediately before applying nx.single_source_shortest_path_length seems to "fix" it.  This explains why dbt-core>=1.1 works correctly because we changed the method used to reverse the graph to one that actually iterates over it.  This makes absolutely no sense since iterating over the graph should not mutate it in any way!!!
I suspect that either we are constructing the initial graph in such a way that causes problems unless it's iterated over OR there's a bug in networkx somewhere very very very not obvious.  Unfortunately, I wasn't able to definitively pin down the source of this bug despite several days worth of effort.

@iknox-fa My inclination here is to move forward with the refactor that you've identified, after several days of detailed investigation. This is critical dbt functionality. It feels most important that we are confident in the approach we're taking going forward—specifically, that it is closely aligned with intended behavior of networkx.
We've now pinned dbt-core v1.0 to use networkx<2.8.1. dbt-core v1.1 is still allowing networkx<3 (since this error didn't occur there). Since we don't feel like we fully understand exactly why the extra iteration step added in v1.1 is working, let's either:

Backport the change in #5326 to 1.1.latest
Pin v1.1 to a tighter upper bound of networkx

@jtcohen6 I like pinning 1.1 and not backporting since it's a change that introduces risk. We can add that to the RC2 that we are going to push out soon

@leahwicz Agree with pinning as the safer bet for v1.1. Let's make sure that gets in for RC2.

I spent some time debugging this issue this morning. Two videos for you:
First, A walkthrough of using git bisect to find the first commit which breaks the graph traversal behavior in dbt Core
https://www.loom.com/share/084a91690e6744738063ad78c7b5e79e
The first commit in Networkx which causes the errant behavior is: https://github.com/networkx/networkx/commit/f50fc70b8cb6b4f5217a6d5505ba0e2b82b4761b
Second, A deep dive with a debugger to figure out the root cause of the regression. I feel like I'm 90% of the way to understanding the culprit, but I'm missing the specific place where (surprise!) a cache is not being invalidated/updated
https://www.loom.com/share/a67fa29caaac436997e278742d61c031
Here's the code that I'm using to repro this issue: https://gist.github.com/drewbanin/60f3b6a5d19d8af694dc6830c8c986b3


OR with the same value

My problem is that i will check is value x in the column a or b exist.
How I can do this?
I get: SQLSTATE[HY093]: Invalid parameter number: parameter was not defined
I tried:
$DB->query("SELECT * FROM accounting_entries WHERE soll=:nr OR haben=:nr", array('nr'=>$this->nr));

Each parameter can only be used once, which seems to be a limitation of PDO.

$DB->query("SELECT * FROM accounting_entries WHERE soll=:nr OR haben=:nr2", array('nr'=>$this->nr, 'nr2'=>$this->nr));

Thanks for the response.

Yeah but it would be great it the repo could handle this
because for this query
DB::rs()->query(
            "SELECT
                    (CASE
                        WHEN U.status = 'pending' AND C.users_id = ? THEN 0
                        WHEN U.status = 'pending' AND U.utilisateur_id = ? THEN -1
                        WHEN U.status = 'accepted' AND C.users_id = ? THEN -2
                        WHEN U.status = 'refused' AND C.users_id = ? THEN -3
                        WHEN U.status = 'cancelled' AND C.users_id = ? THEN -4
                        WHEN U.status = 'accepted' AND C.users_id = ? THEN -5
                        WHEN U.status = 'refused' AND C.users_id = ? THEN -6
                        WHEN U.status = 'cancelled' AND C.users_id = ? THEN -7
                        ELSE -8
                     END) AS orderBy
                    FROM blabla
                    WHERE C.users_id = ?
                    ORDER BY orderBy DESC",

I have to use ? with  array_fill(0, 9, $user['id']) instead of just :userId and 'userId' => $user['id']


Allow * in array of origin

I added origin via env variable like so:
app.enableCors({
    origin: configService.get<string>('CORS_ORIGIN')!.split(','),
});

This allowed you to specify multiple domains separated by commas
But I didn’t understand why it didn’t work if I wrote CORS_ORIGIN: *
After looking at the source code i saw that there is no check for * in the array of origins
So I think that no matter if I write like this * or so [*] the result should be the same

Thank you. We likely need to wait to land this until we are spinning up a new major version of this module. See #185


docs: fix docs and controls gone in storybook

Removes a rouge comma to bring back the docs tab in storybook as well as the controls.

Awesome!


Project fails to build: "Property 'restart' does not exist on type 'Merlin'."

Looks like https://github.com/freebroccolo/ocaml-language-server/commit/afdd40b65e64cbb1de443a0e808db92ce47d877f has caused a build break, since merlin.ts doesn't contain a restart() function.
><EMAIL_ADDRESS>lint /Users/wipi/Projects/ocaml-language-server
> tslint --project tsconfig.json

src/bin/server/command/restartMerlin.ts(6,18): error TS2339: Property 'restart' does not exist on type 'Merlin'.

6   session.merlin.restart();
                   ~~~~~~~

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>build: `npm run build:pegjs:ocamldoc && npm run format && npm run lint && tsc -p ./`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/wipi/.npm/_logs/2017-11-29T17_08_38_307Z-debug.log
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Thanks!


Hints not shown when limit equals count of nodes in dataset

Hi there!
In our web application we use typeahead.js to give hints for item id's. Works fine as long as there are more than five (5) items in the dataset with hints. But when there are exactly five or less items to show, the results aren't the expected ones.
As datasource we use a Bloodhound object with Remote (without Prefetch).
When you search for "at90v" our program returns the following list:
["AT90V10","AT90V100","AT90V12","AT90V15","AT90V15/12","AT90V20","AT90V20/12","AT90V20/15","AT90V25","AT90V25/15","AT90V25/20"]
and typeahead.js shows the first five items (as expected).
But when you search for "at90v1" (one character more), our program returns the following list:
["AT90V10","AT90V100","AT90V12","AT90V15","AT90V15/12"]
and typeahead.js shows zero hints.
I also tried to modify our program always to return only five items, but then typeahead.js completely stopped working.
Following the most important code snippets from our JavaScript file where typeahead.js is initialized.
You can find the full JavaScript file here: holterOnline.app.js (used in combination with holterOnline.lib.js).
dataSource = new Bloodhound({     datumTokenizer: Bloodhound.tokenizers.whitespace,     queryTokenizer: Bloodhound.tokenizers.whitespace,     remote: {         url: programmAufruf + '&SUCHBEGR=%QUERY',         wildcard: '%QUERY',         transform: formatiereDaten     } });
$elem.typeahead({     hint: false,     highlight: true,     minLength: 1 }, {     name: 'dsTypeahead' + pgmn,     source: dataSource });
var formatiereDaten = function (response) {     response.forEach(function (element, index, array) {         array[index] = decodeURIComponent(element);     });     return response; };
Issue #1653 was about the same topic, but was closed without being fixed.
I tried to fix this bug on my own (Pull requests #1659 and #1660 ) but I made something wrong - the Travis CI build failed.

See #1662 - issue fixed, Travis CI passed


Suggestions for the TM4 administration guide

As per request of @michael63-osm I checked on the administration guide. And some other things and put my suggestions into this PR.
I haven't finished on everything, yet. And will continue next week with the review. I can either continue on this PR or if it gets accepted before, I can create a new one for more input. Both is totally fine for me.
Many thanks for putting this together. I'm happy to talk or answer questions to my changes, if you have any doubts.

Hi,
I've had a quick read through - looks good. I've just made a commit to the translations config file (https://github.com/Nick-Tallguy/Nick-Tallguy.github.io/commit/12e4fae3e6ce22769fdc1aa6e39d82b45cadd0be) so that any translations from transifex of 0500-10-20-remotemd or 0500-10-24-tasking-manager-adminmd are not pulled down from transifex - temporary to prevent overwriting by automated downloads each morning. Will need updating when we have the updated versions on transifex.

I've pulled this in now to avoid possible confilcts shortly - doing some work which may affect filenames.

When this work is complete, in this order, we need to;

Upload the updated file to transifex, then
Update the config file in translations folder, where the files are currently commented out to prevent downloads overwriting the new files.

I've locked 0500-10-20-remote on Transifex to stop translations until we upload the new version.


feat(HACBS-2290): use snapshot from workspace in release pipelines

Tekton parameters and results have a 4096 character limit. To work around this, the snapshot should be saved in a workspace that is shared among tasks. This commit accomplishes that.

$ diff -r 0.3 0.4
diff -r 0.3/deploy-release.yaml 0.4/deploy-release.yaml
7c7
<     app.kubernetes.io/version: "0.3"
---
>     app.kubernetes.io/version: "0.4"
14a15,27
>     - name: release
>       type: string
>       description:
>         The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution
>     - name: releaseplan
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlan
>     - name: releaseplanadmission
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlanAdmission
>     - name: releasestrategy
>       type: string
>       description: The namespaced name (namespace/name) of the releaseStrategy
17c30
<       description: The Snapshot in JSON format
---
>       description: The namespaced name (namespace/name) of the snapshot
23a37,38
>   workspaces:
>     - name: release-workspace
24a40,56
>     - name: collect-data
>       taskRef:
>         name: collect-data
>       params:
>         - name: release
>           value: $(params.release)
>         - name: releaseplan
>           value: $(params.releaseplan)
>         - name: releaseplanadmission
>           value: $(params.releaseplanadmission)
>         - name: releasestrategy
>           value: $(params.releasestrategy)
>         - name: snapshot
>           value: $(params.snapshot)
>       workspaces:
>         - name: data
>           workspace: release-workspace
30c62
<             value: $(params.verify_ec_task_bundle)
---
>             value: quay.io/jstuart/verify-enterprise-contract@sha256:729a3f2393a3b19708a192709d8f737392f4fcbb5295216f3f7cf242c9d7dd74
34c66
<             value: verify-enterprise-contract
---
>             value: verify-enterprise-contract
37c69
<           value: $(params.snapshot)
---
>           value: "snapshot_spec.json"
43a76,80
>       workspaces:
>         - name: data
>           workspace: release-workspace
>       runAfter:
>         - collect-data
diff -r 0.3/README.md 0.4/README.md
9c9,13
< | snapshot | The Snapshot in JSON format | No | - |
---
> | release | The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution | No | - |
> | releaseplan | The namespaced name (namespace/name) of the releasePlan | No | - |
> | releaseplanadmission | The namespaced name (namespace/name) of the releasePlanAdmission | No | - |
> | releasestrategy | The namespaced name (namespace/name) of the releaseStrategy | No | - |
> | snapshot | The namespaced name (namespace/name) of the snapshot | No | - |
13c17,24
< ### Changes since 0.2
---
> ## Changes since 0.3
> - the collect-data task was added
>     - this includes adding the required parameters release, releaseplan, releaseplanadmission,
>       and releasestrategy as pipeline parameters
>     - a workspace is now mounted by the pipeline as required by this task
> - the snapshot parameter is now a namespaced name instead of a JSON string
>
> ## Changes since 0.2
diff -r 0.3/samples/sample_release_PipelineRun.yaml 0.4/samples/sample_release_PipelineRun.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
18c26
<         value: quay.io/hacbs-release/pipeline-deploy-release:0.3
---
>         value: quay.io/hacbs-release/pipeline-deploy-release:0.4
diff -r 0.3/tests/run.yaml 0.4/tests/run.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
18c26
<         value: quay.io/hacbs-release/pipeline-deploy-release:0.3
---
>         value: quay.io/hacbs-release/pipeline-deploy-release:0.4

$ diff -r 0.15 0.16
diff -r 0.15/fbc-release.yaml 0.16/fbc-release.yaml
7c7
<     app.kubernetes.io/version: "0.15"
---
>     app.kubernetes.io/version: "0.16"
14a15,27
>     - name: release
>       type: string
>       description:
>         The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution
>     - name: releaseplan
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlan
>     - name: releaseplanadmission
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlanAdmission
>     - name: releasestrategy
>       type: string
>       description: The namespaced name (namespace/name) of the releaseStrategy
17c30
<       description: The Snapshot in JSON format
---
>       description: The namespaced name (namespace/name) of the snapshot
21,24d33
<     - name: release
<       type: string
<       description:
<         The namespaced name (namespace/releaseName) of the Release custom resource initiating this pipeline execution
75a85,101
>     - name: collect-data
>       taskRef:
>         name: collect-data
>       params:
>         - name: release
>           value: $(params.release)
>         - name: releaseplan
>           value: $(params.releaseplan)
>         - name: releaseplanadmission
>           value: $(params.releaseplanadmission)
>         - name: releasestrategy
>           value: $(params.releasestrategy)
>         - name: snapshot
>           value: $(params.snapshot)
>       workspaces:
>         - name: data
>           workspace: release-workspace
81c107
<             value: $(params.verify_ec_task_bundle)
---
>             value: quay.io/jstuart/verify-enterprise-contract@sha256:729a3f2393a3b19708a192709d8f737392f4fcbb5295216f3f7cf242c9d7dd74
88c114
<           value: $(params.snapshot)
---
>           value: "snapshot_spec.json"
94a121,125
>       workspaces:
>         - name: data
>           workspace: release-workspace
>       runAfter:
>         - collect-data
100,107c131
<         resolver: "bundles"
<         params:
<           - name: bundle
<             value: quay.io/hacbs-release/task-create-internal-request:0.6
<           - name: kind
<             value: task
<           - name: name
<             value: create-internal-request
---
>         name: create-internal-request
132,133c156
<               value: '$(params.snapshot)'
<               jsonKey: ".components[0].containerImage"
---
>               value: "$(tasks.collect-data.results.fbcFragment)"
166,173c189
<         resolver: "bundles"
<         params:
<           - name: bundle
<             value: quay.io/hacbs-release/task-create-internal-request:0.6
<           - name: kind
<             value: task
<           - name: name
<             value: create-internal-request
---
>         name: create-internal-request
diff -r 0.15/README.md 0.16/README.md
9c9,13
< | snapshot | The Snapshot in JSON format | No | - |
---
> | release | The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution | No | - |
> | releaseplan | The namespaced name (namespace/name) of the releasePlan | No | - |
> | releaseplanadmission | The namespaced name (namespace/name) of the releasePlanAdmission | No | - |
> | releasestrategy | The namespaced name (namespace/name) of the releaseStrategy | No | - |
> | snapshot | The namespaced name (namespace/name) of the snapshot | No | - |
11d14
< | release | The namespaced name (namespace/releaseName) of the Release custom resource initiating this pipeline execution | No | - |
25a29,35
>
> ### Changes since 0.15
> - the collect-data task was added
>     - this includes adding the required parameters releaseplan, releaseplanadmission, and
>       releasestrategy as pipeline parameters
> - the snapshot parameter is now a namespaced name instead of a JSON string
>     - task versions were updated in accordance with this change
diff -r 0.15/samples/sample_release_PipelineRun.yaml 0.16/samples/sample_release_PipelineRun.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
42c50
<         value: quay.io/hacbs-release/pipeline-fbc-release:0.15
---
>         value: quay.io/hacbs-release/pipeline-fbc-release:0.16
diff -r 0.15/tests/run.yaml 0.16/tests/run.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
42c50
<         value: quay.io/hacbs-release/pipeline-fbc-release:0.15
---
>         value: quay.io/hacbs-release/pipeline-fbc-release:0.16

$ diff -r 0.11 0.12
diff -r 0.11/push-to-external-registry.yaml 0.12/push-to-external-registry.yaml
7c7
<     app.kubernetes.io/version: "0.11"
---
>     app.kubernetes.io/version: "0.12"
14a15,27
>     - name: release
>       type: string
>       description:
>         The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution
>     - name: releaseplan
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlan
>     - name: releaseplanadmission
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlanAdmission
>     - name: releasestrategy
>       type: string
>       description: The namespaced name (namespace/name) of the releaseStrategy
17c30
<       description: The Snapshot in JSON format
---
>       description: The namespaced name (namespace/name) of the snapshot
64a78,101
>     - name: collect-data
>       taskRef:
>         resolver: "bundles"
>         params:
>           - name: bundle
>             value: quay.io/hacbs-release/task-collect-data:0.1
>           - name: kind
>             value: task
>           - name: name
>             value: collect-data
>       params:
>         - name: release
>           value: $(params.release)
>         - name: releaseplan
>           value: $(params.releaseplan)
>         - name: releaseplanadmission
>           value: $(params.releaseplanadmission)
>         - name: releasestrategy
>           value: $(params.releasestrategy)
>         - name: snapshot
>           value: $(params.snapshot)
>       workspaces:
>         - name: data
>           workspace: release-workspace
94c131
<             value: quay.io/hacbs-release/task-apply-mapping:0.4
---
>             value: quay.io/hacbs-release/task-apply-mapping:0.5
100,101d136
<         - name: snapshot
<           value: $(params.snapshot)
112a148,149
>       runAfter:
>         - collect-data
125c162
<           value: $(tasks.apply-mapping.results.snapshot)
---
>           value: "mapped_snapshot.json"
131a169,173
>       workspaces:
>         - name: data
>           workspace: release-workspace
>       runAfter:
>         - apply-mapping
137c179
<             value: quay.io/hacbs-release/task-push-snapshot:0.7
---
>             value: quay.io/hacbs-release/task-push-snapshot:0.8
143,144d184
<         - name: mappedSnapshot
<           value: $(tasks.apply-mapping.results.snapshot)
152a193,195
>       workspaces:
>         - name: data
>           workspace: release-workspace
160c203
<             value: quay.io/hacbs-release/task-create-pyxis-image:0.3
---
>             value: quay.io/hacbs-release/task-create-pyxis-image:0.4
172,173c215,217
<         - name: mappedSnapshot
<           value: $(tasks.apply-mapping.results.snapshot)
---
>       workspaces:
>         - name: data
>           workspace: release-workspace
181c225
<             value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.1
---
>             value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.2
187,188d230
<         - name: mappedSnapshot
<           value: $(tasks.apply-mapping.results.snapshot)
194a237,239
>       workspaces:
>         - name: data
>           workspace: release-workspace
diff -r 0.11/README.md 0.12/README.md
9c9,13
< | snapshot | The Snapshot in JSON format | No | - |
---
> | release | The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution | No | - |
> | releaseplan | The namespaced name (namespace/name) of the releasePlan | No | - |
> | releaseplanadmission | The namespaced name (namespace/name) of the releasePlanAdmission | No | - |
> | releasestrategy | The namespaced name (namespace/name) of the releaseStrategy | No | - |
> | snapshot | The namespaced name (namespace/name) of the snapshot | No | - |
23,25c27,36
< ### Changes since 0.10
< - the verify_ec_task_bundle parameter was added
<     - with this addition, the verify-enterprise-contract task version is no longer static
---
> ## Changes since 0.11
> * the collect-data task was added
>   * this includes adding the required parameters release, releaseplan, releaseplanadmission,
>       and releasestrategy as pipeline parameters
> * the snapshot parameter is now a namespaced name instead of a JSON string
>   * task versions were updated in accordance with this change
>
> ## Changes since 0.10
> * the verify_ec_task_bundle parameter was added
>   * with this addition, the verify-enterprise-contract task version is no longer static
diff -r 0.11/samples/sample_push-to-external-registry_PipelineRun.yaml 0.12/samples/sample_push-to-external-registry_PipelineRun.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
32c40
<         value: quay.io/hacbs-release/pipeline-push-to-external-registry:0.11
---
>         value: quay.io/hacbs-release/pipeline-push-to-external-registry:0.12
diff -r 0.11/tests/run.yaml 0.12/tests/run.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
32c40
<         value: quay.io/hacbs-release/pipeline-push-to-external-registry:0.11
---
>         value: quay.io/hacbs-release/pipeline-push-to-external-registry:0.12

$ diff -r 0.14 0.15
diff -r 0.14/README.md 0.15/README.md
9c9,13
< | snapshot | The Snapshot in JSON format | No | - |
---
> | release | The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution | No | - |
> | releaseplan | The namespaced name (namespace/name) of the releasePlan | No | - |
> | releaseplanadmission | The namespaced name (namespace/name) of the releasePlanAdmission | No | - |
> | releasestrategy | The namespaced name (namespace/name) of the releaseStrategy | No | - |
> | snapshot | The namespaced name (namespace/name) of the snapshot | No | - |
17a22,28
> ## Changes since 0.14
> * the collect-data task was added
>   * this includes adding the required parameters release, releaseplan, releaseplanadmission,
>       and releasestrategy as pipeline parameters
> * the snapshot parameter is now a namespaced name instead of a JSON string
>   * task versions were updated in accordance with this change
>
21d31
< * push-snapshot task pinned to version 0.7 instead of main
diff -r 0.14/release.yaml 0.15/release.yaml
7c7
<     app.kubernetes.io/version: "0.14"
---
>     app.kubernetes.io/version: "0.15"
14a15,27
>     - name: release
>       type: string
>       description:
>         The namespaced name (namespace/name) of the Release custom resource initiating this pipeline execution
>     - name: releaseplan
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlan
>     - name: releaseplanadmission
>       type: string
>       description: The namespaced name (namespace/name) of the releasePlanAdmission
>     - name: releasestrategy
>       type: string
>       description: The namespaced name (namespace/name) of the releaseStrategy
17c30
<       description: The Snapshot in JSON format
---
>       description: The namespaced name (namespace/name) of the snapshot
46a60,83
>     - name: collect-data
>       taskRef:
>         resolver: "bundles"
>         params:
>           - name: bundle
>             value: quay.io/hacbs-release/task-collect-data:0.1
>           - name: kind
>             value: task
>           - name: name
>             value: collect-data
>       params:
>         - name: release
>           value: $(params.release)
>         - name: releaseplan
>           value: $(params.releaseplan)
>         - name: releaseplanadmission
>           value: $(params.releaseplanadmission)
>         - name: releasestrategy
>           value: $(params.releasestrategy)
>         - name: snapshot
>           value: $(params.snapshot)
>       workspaces:
>         - name: data
>           workspace: release-workspace
76c113
<             value: quay.io/hacbs-release/task-apply-mapping:0.4
---
>             value: quay.io/hacbs-release/task-apply-mapping:0.5
82,83d118
<         - name: snapshot
<           value: $(params.snapshot)
94a130,131
>       runAfter:
>         - collect-data
107c144
<           value: $(tasks.apply-mapping.results.snapshot)
---
>           value: "mapped_snapshot.json"
113a151,155
>       workspaces:
>         - name: data
>           workspace: release-workspace
>       runAfter:
>         - apply-mapping
119c161
<             value: quay.io/hacbs-release/task-push-snapshot:0.7
---
>             value: quay.io/hacbs-release/task-push-snapshot:0.8
125,126d166
<         - name: mappedSnapshot
<           value: $(tasks.apply-mapping.results.snapshot)
128a169,171
>       workspaces:
>         - name: data
>           workspace: release-workspace
diff -r 0.14/samples/sample_release_PipelineRun.yaml 0.15/samples/sample_release_PipelineRun.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
26c34
<         value: quay.io/hacbs-release/pipeline-release:0.14
---
>         value: quay.io/hacbs-release/pipeline-release:0.15
diff -r 0.14/tests/run.yaml 0.15/tests/run.yaml
7a8,15
>     - name: release
>       value: ""
>     - name: releaseplan
>       value: ""
>     - name: releaseplanadmission
>       value: ""
>     - name: releasestrategy
>       value: ""
26c34
<         value: quay.io/hacbs-release/pipeline-release:0.14
---
>         value: quay.io/hacbs-release/pipeline-release:0.15

$ diff -r 0.4 0.5
diff -r 0.4/apply-mapping.yaml 0.5/apply-mapping.yaml
7c7
<     app.kubernetes.io/version: "0.4"
---
>     app.kubernetes.io/version: "0.5"
15c15
<     - name: snapshot
---
>     - name: snapshotPath
17c17,18
<       description: The Snapshot in JSON format to apply the mapping to
---
>       description: Path to the JSON string of the Snapshot spec in the config workspace to apply the mapping to
>       default: "snapshot_spec.json"
28c29
<       description: The workspace where the extra config file containing the mapping resides
---
>       description: The workspace where the extra config file containing the mapping and snapshot json reside
30,33d30
<     - name: snapshot
<       description: |
<         The Snapshot in JSON format with the mapping applied. If there is no mapping key in the
<         extraConfigPath, this result will be the same as the original snapshot parameter.
40,42d36
<       env:
<         - name: "SNAPSHOT"
<           value: '$(params.snapshot)'
46a41,49
>         SNAPSHOT_SPEC_FILE="$(workspaces.config.path)/$(params.snapshotPath)"
>         if [ ! -f "${SNAPSHOT_SPEC_FILE}" ] ; then
>             echo "No valid snapshot file was provided."
>             exit 1
>         fi
>
>         # The mapped_snapshot file will be overwritten below if the CONFIG_FILE is valid
>         cp "${SNAPSHOT_SPEC_FILE}" "$(workspaces.config.path)/mapped_snapshot.json"
>
50d52
<             echo "${SNAPSHOT}" | tee $(results.snapshot.path)
56d57
<             echo "${SNAPSHOT}" | tee $(results.snapshot.path)
65,69c66,70
<         # Save the output as a compact json in snapshot task result
<         jq -c -s '.[0] as $snapshot | .[0].components + .[1].mapping.components | group_by(.name)
<           | [.[] | select(length > 1)] | map(reduce .[] as $x ({}; . * $x)) as $mergedComponents
<           | $snapshot | .components = $mergedComponents' \
<           <<< "${SNAPSHOT}${CONFIG_JSON}" | tee $(results.snapshot.path)
---
>         # Save the output as a compact json in mapped_snapshot.json file in the workspace
>         { echo -n $(cat "${SNAPSHOT_SPEC_FILE}"); echo "${CONFIG_JSON}"; } | jq -c -s '.[0] as $snapshot
>           | .[0].components + .[1].mapping.components | group_by(.name) | [.[] | select(length > 1)]
>           | map(reduce .[] as $x ({}; . * $x)) as $mergedComponents | $snapshot | .components = $mergedComponents' \
>           > "$(workspaces.config.path)/mapped_snapshot.json"
73c74,75
<         if [ "$(params.failOnEmptyResult)" = "true" ] && [ $(jq '.components | length' $(results.snapshot.path)) -eq 0 ]
---
>         if [ "$(params.failOnEmptyResult)" = "true" ] && \
>           [ $(cat "$(workspaces.config.path)/mapped_snapshot.json" | jq '.components | length') -eq 0 ]
diff -r 0.4/README.md 0.5/README.md
17c17
< | snapshot | The Snapshot in JSON format to apply the mapping to | No | - |
---
> | snapshotPath | Path to the JSON string of the Snapshot spec in the config workspace to apply the mapping to | Yes | snapshot_spec.json |
19a20,24
>
> ## Changes since 0.4
>   * The snapshot parameter was replaced with the snapshotPath parameter
>     * The snapshot is now provided via the workspace instead of directly as a parameter
>     * The mapped snapshot is now stored in a `mapped_snapshot.json` file in the workspace instead of as a task result
diff -r 0.4/samples/sample_apply-mapping_TaskRun.yaml 0.5/samples/sample_apply-mapping_TaskRun.yaml
7,9d6
<   params:
<     - name: snapshot
<       value: ""
14c11
<         value: quay.io/hacbs-release/task-apply-mapping:0.4
---
>         value: quay.io/hacbs-release/task-apply-mapping:0.5
diff -r 0.4/tests/test-apply-mapping-fail-on-empty.yaml 0.5/tests/test-apply-mapping-fail-on-empty.yaml
43c43
<               cat > $(results.snapshot.path) << EOF
---
>               cat > "$(workspaces.config.path)/snapshot_spec.json" << EOF
67,68c67,68
<         - name: snapshot
<           value: $(tasks.setup.results.snapshot)
---
>         - name: snapshotPath
>           value: "snapshot_spec.json"
75a76,77
>       runAfter:
>         - setup
diff -r 0.4/tests/test-apply-mapping-no-mapping.yaml 0.5/tests/test-apply-mapping-no-mapping.yaml
13a14,16
>       workspaces:
>         - name: config
>           workspace: tests-workspace
16a20,21
>         workspaces:
>           - name: config
24c29
<               cat > $(results.snapshot.path) << EOF
---
>               cat > $(workspaces.config.path)/snapshot_spec.json << EOF
53,54d57
<         - name: snapshot
<           value: $(tasks.setup.results.snapshot)
59a63,64
>       runAfter:
>         - setup
61,65c66,68
<       params:
<         - name: origSnapshot
<           value: $(tasks.setup.results.snapshot)
<         - name: mappedSnapshot
<           value: $(tasks.run-task.results.snapshot)
---
>       workspaces:
>         - name: config
>           workspace: tests-workspace
67,71c70,71
<         params:
<           - name: origSnapshot
<             type: string
<           - name: mappedSnapshot
<             type: string
---
>         workspaces:
>           - name: config
75,79d74
<             env:
<               - name: "ORIG"
<                 value: '$(params.origSnapshot)'
<               - name: "MAPPED"
<                 value: '$(params.mappedSnapshot)'
85a81,82
>       runAfter:
>         - run-task
diff -r 0.4/tests/test-apply-mapping.yaml 0.5/tests/test-apply-mapping.yaml
20,21d19
<         results:
<           - name: snapshot
44c42
<               cat > $(results.snapshot.path) << EOF
---
>               cat > $(workspaces.config.path)/test_snapshot_spec.json << EOF
77,78c75,76
<         - name: snapshot
<           value: $(tasks.setup.results.snapshot)
---
>         - name: snapshotPath
>           value: test_snapshot_spec.json
87,89c85,87
<       params:
<         - name: snapshot
<           value: $(tasks.run-task.results.snapshot)
---
>       workspaces:
>         - name: config
>           workspace: tests-workspace
91,93c89,90
<         params:
<           - name: snapshot
<             type: string
---
>         workspaces:
>           - name: config
97,99d93
<             env:
<               - name: "SNAPSHOT"
<                 value: '$(params.snapshot)'
105c99,100
<               test $(echo $SNAPSHOT|jq -r '[ .components[] | select(.name=="comp1") ] | length') -eq 1
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '[ .components[] | select(.name=="comp1") ] | length') -eq 1
108c103,104
<               test $(echo $SNAPSHOT|jq -r '.components[] | select(.name=="comp1") | .repository') == repo1
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '.components[] | select(.name=="comp1") | .repository') == repo1
111c107,108
<               test $(echo $SNAPSHOT|jq -r '[ .components[] | select(.name=="comp2") ] | length') -eq 0
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '[ .components[] | select(.name=="comp2") ] | length') -eq 0
114c111,112
<               test $(echo $SNAPSHOT|jq -r '.components[] | select(.name=="comp3") | .repository') == repo3a
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '.components[] | select(.name=="comp3") | .repository') == repo3a
117c115,116
<               test $(echo $SNAPSHOT|jq -r '.components[] | select(.name=="comp4") | .repository') == repo4
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '.components[] | select(.name=="comp4") | .repository') == repo4
120c119,122
<               test $(echo $SNAPSHOT|jq -r '[ .components[] | select(.name=="comp5") ] | length') -eq 0
---
>               test $(cat $(workspaces.config.path)/mapped_snapshot.json \
>                 | jq -r '[ .components[] | select(.name=="comp5") ] | length') -eq 0
>       runAfter:
>         - run-task

$ diff -r 0.3 0.4
diff -r 0.3/create-pyxis-image.yaml 0.4/create-pyxis-image.yaml
7c7
<     app.kubernetes.io/version: "0.3"
---
>     app.kubernetes.io/version: "0.4"
34c34
<     - name: mappedSnapshot
---
>     - name: snapshotPath
36c36,40
<       description: The mapped snapshot in JSON format
---
>       description: Path to the JSON string of the mapped Snapshot spec in the data workspace
>       default: mapped_snapshot.json
>   workspaces:
>     - name: data
>       description: The workspace where the snapshot spec json file resides
69a74,79
>         SNAPSHOT_SPEC_FILE="$(workspaces.data.path)/$(params.snapshotPath)"
>         if [ ! -f "${SNAPSHOT_SPEC_FILE}" ] ; then
>             echo "No valid snapshot file was provided."
>             exit 1
>         fi
>
73c83
<         for containerImage in $(jq -r '.components[].repository' <<< '$(params.mappedSnapshot)') ; do
---
>         for containerImage in $(jq -r '.components[].repository' "${SNAPSHOT_SPEC_FILE}") ; do
diff -r 0.3/README.md 0.4/README.md
19c19,24
< | mappedSnapshot | The mapped snapshot in JSON format | No | - |
---
> | snapshotPath | Path to the JSON string of the mapped Snapshot spec in the data workspace | Yes | mapped_snapshot.json |
>
> ## Changes since 0.3
> * mappedSnapshot parameter was removed and snapshotPath parameter was added
>   * Instead of passing a json string representing the snapshot, the snapshot spec should exist in the data workspace
>     in the filename provided by snapshotPath.
diff -r 0.3/samples/sample_create-pyxis-image_TaskRun.yaml 0.4/samples/sample_create-pyxis-image_TaskRun.yaml
12,13d11
<     - name: mappedSnapshot
<       value: ""
18c16
<         value: quay.io/hacbs-release/task-create-pyxis-image:0.3
---
>         value: quay.io/hacbs-release/task-create-pyxis-image:0.4
diff -r 0.3/tests/run.yaml 0.4/tests/run.yaml
12,13d11
<     - name: mappedSnapshot
<       value: ""
18c16
<         value: quay.io/hacbs-release/task-create-pyxis-image:0.3
---
>         value: quay.io/hacbs-release/task-create-pyxis-image:0.4

$ diff -r 0.1 0.2
diff -r 0.1/push-sbom-to-pyxis.yaml 0.2/push-sbom-to-pyxis.yaml
7c7
<     app.kubernetes.io/version: "0.1"
---
>     app.kubernetes.io/version: "0.2"
15,16c15,16
<     - name: mappedSnapshot
<       description: The mapped snapshot in JSON format
---
>     - name: snapshotPath
>       description: Path to the JSON string of the mapped Snapshot spec in hte data workspace
17a18
>       default: mapped_snapshot.json
28a30,32
>   workspaces:
>     - name: data
>       description: The workspace where the snapshot spec json file resides
43c47,53
<         IMAGEURLS=($(jq -r '.components[].containerImage' <<< '$(params.mappedSnapshot)'))
---
>         SNAPSHOT_SPEC_FILE="$(workspaces.data.path)/$(params.snapshotPath)"
>         if [ ! -f "${SNAPSHOT_SPEC_FILE}" ] ; then
>             echo "No valid snapshot file was provided."
>             exit 1
>         fi
>
>         IMAGEURLS=($(cat "${SNAPSHOT_SPEC_FILE}" | jq -r '.components[].containerImage'))
61c71
<         quay.io/hacbs-release/release-utils:7c19cfb26869fb2c76c3a6b0eaad6408ead66c56
---
>         quay.io/hacbs-release/release-utils:5b1a1cd9fd68625cab5573ce62e0d87e6f93f341
diff -r 0.1/README.md 0.2/README.md
9c9
< | mappedSnapshot | The mapped snapshot in JSON format | No | - |
---
> | snapshotPath | Path to the JSON string of the mapped Snapshot spec in the data workspace | Yes | mapped_snapshot.json |
12a13,17
>
> ## Changes since 0.1
> * mappedSnapshot parameter was removed and snapshotPath parameter was added
>   * Instead of passing a json string representing the snapshot, the snapshot spec should exist in the data workspace
>     in the filename provided by snapshotPath.
diff -r 0.1/sample/sample_push-sbom-to-pyxis_TaskRun.yaml 0.2/sample/sample_push-sbom-to-pyxis_TaskRun.yaml
8,9d7
<     - name: mappedSnapshot
<       value: ""
18c16
<         value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.1
---
>         value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.2
diff -r 0.1/tests/run.yaml 0.2/tests/run.yaml
8,9d7
<     - name: mappedSnapshot
<       value: ""
18c16
<         value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.1
---
>         value: quay.io/hacbs-release/task-push-sbom-to-pyxis:0.2

diff -r 0.7/push-snapshot.yaml 0.8/push-snapshot.yaml
7c7
<     app.kubernetes.io/version: "0.7"
---
>     app.kubernetes.io/version: "0.8"
15,16c15,16
<     - name: mappedSnapshot
<       description: JSON string representing the Snapshot
---
>     - name: snapshotPath
>       description: Path to the JSON string of the mapped Snapshot spec in the data workspace
17a18
>       default: "mapped_snapshot.json"
37a39,41
>   workspaces:
>     - name: data
>       description: The workspace where the snapshot spec json file resides
57c61,67
<         application=$(jq -r '.application' <<<'$(params.mappedSnapshot)')
---
>         SNAPSHOT_SPEC_FILE="$(workspaces.data.path)/$(params.snapshotPath)"
>         if [ ! -f "${SNAPSHOT_SPEC_FILE}" ] ; then
>             echo "No valid snapshot file was provided."
>             exit 1
>         fi
>
>         application=$(jq -r '.application' "${SNAPSHOT_SPEC_FILE}")
59c69
<         for component in $(jq -rc '.components[]' <<< '$(params.mappedSnapshot)')
---
>         for component in $(jq -rc '.components[]' "${SNAPSHOT_SPEC_FILE}")
diff -r 0.7/README.md 0.8/README.md
7,14c7,19
< | Name            | Description                                                                                | Optional | Default value |
< |-----------------|-------------------------------------------------------------------------------------------------|----------|---------------|
< | mappedSnapshot  | JSON string representing the Snapshot                                                           | No       | -             |
< | tag             | Default tag to use if mapping entry does not contain a tag                                      | Yes      | latest        |
< | retries         | Retry copy N times                                                                              | Yes      | 0             |
< | addGitShaTag    | Also push a tag with the git sha for each image in the Snapshot                                 | Yes      | true          |
< | addSourceShaTag | Also push a tag with the source sha for each image in the Snapshot                              | Yes      | true          |
< | addTimestampTag | Also push a tag with the current timestamp for each image in the Snapshot                       | Yes      | false         |
---
> | Name            | Description                                                                                | Optional | Default value        |
> |-----------------|-------------------------------------------------------------------------------------------------|----------|----------------------|
> | snapshotPath    | Path to the JSON string of the mapped Snapshot spec in the data workspace                       | Yes      | mapped_snapshot.json |
> | tag             | Default tag to use if mapping entry does not contain a tag                                      | Yes      | latest               |
> | retries         | Retry copy N times                                                                              | Yes      | 0                    |
> | addGitShaTag    | Also push a tag with the git sha for each image in the Snapshot                                 | Yes      | true                 |
> | addSourceShaTag | Also push a tag with the source sha for each image in the Snapshot                              | Yes      | true                 |
> | addTimestampTag | Also push a tag with the current timestamp for each image in the Snapshot                       | Yes      | false                |
>
> ## Changes since 0.7
> * mappedSnapshot parameter was removed and snapshotPath parameter was added
>   * Instead of passing a json string representing the snapshot, the snapshot spec should exist in the data workspace
>     in the filename provided by snapshotPath.
diff -r 0.7/samples/sample_push-snapshot_TaskRun.yaml 0.8/samples/sample_push-snapshot_TaskRun.yaml
8,9d7
<     - name: mappedSnapshot
<       value: ""
16c14
<         value: quay.io/hacbs-release/task-push-snapshot:0.7
---
>         value: quay.io/hacbs-release/task-push-snapshot:0.8
diff -r 0.7/tests/run.yaml 0.8/tests/run.yaml
8,9d7
<     - name: mappedSnapshot
<       value: ""
16c14
<         value: quay.io/hacbs-release/task-push-snapshot:0.7
---
>         value: quay.io/hacbs-release/task-push-snapshot:0.8

30c62
<             value: $(params.verify_ec_task_bundle)

        value: quay.io/jstuart/verify-enterprise-contract@sha256:729a3f2393a3b19708a192709d8f737392f4fcbb5295216f3f7cf242c9d7dd74

I assume this was for testing, right? But I can't see this in the actual changes for the PR.
(BTW, I think it would have been better to provide two commits - one for copying the versions and the other for the changes. That way the diff would be visible in Github directly which is visually nicer than the text output of diff. I think I suggested this before. Maybe I can bring it up in the next retro :) )

30c62
<             value: $(params.verify_ec_task_bundle)

        value: quay.io/jstuart/verify-enterprise-contract@sha256:729a3f2393a3b19708a192709d8f737392f4fcbb5295216f3f7cf242c9d7dd74

I assume this was for testing, right? But I can't see this in the actual changes for the PR.
(BTW, I think it would have been better to provide two commits - one for copying the versions and the other for the changes. That way the diff would be visible in Github directly which is visually nicer than the text output of diff. I think I suggested this before. Maybe I can bring it up in the next retro :) )

Yes, it was for testing. I thought I kept all my testing-only changes in a different branch, but I guess not, my bad. I don't see it in the diff now, but if you do please point it out

30c62
<             value: $(params.verify_ec_task_bundle)

        value: quay.io/jstuart/verify-enterprise-contract@sha256:729a3f2393a3b19708a192709d8f737392f4fcbb5295216f3f7cf242c9d7dd74

I assume this was for testing, right? But I can't see this in the actual changes for the PR.
(BTW, I think it would have been better to provide two commits - one for copying the versions and the other for the changes. That way the diff would be visible in Github directly which is visually nicer than the text output of diff. I think I suggested this before. Maybe I can bring it up in the next retro :) )

Yes, it was for testing. I thought I kept all my testing-only changes in a different branch, but I guess not, my bad. I don't see it in the diff now, but if you do please point it out

I thought we needed to have one commit for the changelog in our actions to be calculated properly. I also am just used to 1 commit per PR from past work. That is why I paste the diffs. But agree, reviewing is a nightmare. More reason why I don't love our current versioning approach or think it is the simplest option

I thought we needed to have one commit for the changelog in our actions to be calculated properly. I also am just used to 1 commit per PR from past work. That is why I paste the diffs. But agree, reviewing is a nightmare. More reason why I don't love our current versioning approach or think it is the simplest option

The issue with multiple commits was upon merging. Because then the changed-files action will only show what was changed in the last commit (if there were several). We mitigated that by enforcing commit squashing when merging.
But having multiple commits in the PR shouldn't be an issue - at least I hope it wouldn't. I know we also rely on the changed-files action in the PR check, but pull request events are different - here I think the changed files should work correctly even with multiple commits, but it knows what commit shas to compare (compared to a merge event where it doesn't know what was there before).
And even if by chance it was still only seeing the last commit, for our scenario it would be fine, right? If there was one commit that duplicates all the tasks/pipelines into new versions and then a second commit that will change those new versions, the last (/second) commit would still contain all the changes to indicate which tasks/pipelines we need to check.
I hope my writing is not too confusing :D

I thought we needed to have one commit for the changelog in our actions to be calculated properly. I also am just used to 1 commit per PR from past work. That is why I paste the diffs. But agree, reviewing is a nightmare. More reason why I don't love our current versioning approach or think it is the simplest option

The issue with multiple commits was upon merging. Because then the changed-files action will only show what was changed in the last commit (if there were several). We mitigated that by enforcing commit squashing when merging.
But having multiple commits in the PR shouldn't be an issue - at least I hope it wouldn't. I know we also rely on the changed-files action in the PR check, but pull request events are different - here I think the changed files should work correctly even with multiple commits, but it knows what commit shas to compare (compared to a merge event where it doesn't know what was there before).
And even if by chance it was still only seeing the last commit, for our scenario it would be fine, right? If there was one commit that duplicates all the tasks/pipelines into new versions and then a second commit that will change those new versions, the last (/second) commit would still contain all the changes to indicate which tasks/pipelines we need to check.
I hope my writing is not too confusing :D

No, that makes sense. I will keep that in mind for my next PR

Leandro tested the fbc pipeline successfully so all changes here are tested now