Go by the word. Test Plan means we are planning for particular scope. We have to test on given environment withing given time frame defined in Test Plan. While the strategies will be common at organization level which is high level description about testing, what kind of testing and where etc.

Use the constructed inventory plugin. See

shell> ansible-doc -t inventory constructed

Create the inventory files

shell> tree inventory/
inventory/
├── 01-TestBoxes
├── 02-ProdBoxes
└── 03-Primary.yml
0 directories, 3 files

shell> cat inventory/01-TestBoxes 
[TestBox:children]
groupA
groupB

[groupA]
host_1

[groupB]
host_2

shell> cat inventory/02-ProdBoxes 
[ProdBox:children]
groupPA
groupPB

[groupPA]
host_P1

[groupPB]
host_P2

shell> cat inventory/03-Primary.yml 
plugin: constructed
groups:
  Primary: (group_names | intersect(['ProdBox', 'TestBox'])) | length > 0

The playbook

shell> cat pb.yml 
- hosts: Primary
  gather_facts: false
  tasks:
    - debug:
        var: inventory_hostname

reads files from the directory inventory in alphabetic order. The file Primary.yml creates the group Primary from hosts that are members of the groups ProdBox and TestBox

shell> ansible-playbook -i inventory pb.yml 
PLAY [Primary] *******************************************************************************
TASK [debug] *********************************************************************************

ok: [host_1] =>

inventory_hostname: host_1

ok: [host_2] =>

inventory_hostname: host_2

ok: [host_P1] =>

inventory_hostname: host_P1

ok: [host_P2] =>

inventory_hostname: host_P2
PLAY RECAP ***********************************************************************************

host_1: ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

host_2: ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

host_P1: ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

host_P2: ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Q: " I have 100+ files like this. and I want to create primary group with few of the files."

A: Create links

shell> tree inventory/
inventory/
├── 01-TestBoxes -> ../hostFiles/TestBoxes
├── 02-ProdBoxes -> ../hostFiles/ProdBoxes
└── 03-Primary.yml

I successfully deployed a fastAPI onto Azure App Services.

However, the environmental variables that I specified into the Configurations > App Settings pane got unexpectedly deleted, thus preventing my app from running correctly and I had to manually recreate the application settings from scratch.

I could save these settings onto my local computer but I am wondering if there is a better way to archive these environment variables.

I think the simplest way to do this would be to utilise a webhook on your Azure DevOps Boards and have it updated via the DevOps API. With a simple serverless instance like Azure Functions you should be able to do this quickly and painlessly.

It's probably easier to create two separate parameters. E.g.:

• Run tests? (boolean parameter)

• If running tests, select tests (multi-select choice parameter)

Then you could code your job to skip all tests if the first parameter is false, otherwise it would run the selected tests.

If you want to get really fancy, you can use the https://plugins.jenkins.io/uno-choice/ to dynamically show the list of tests parameter only if the "run tests" parameter is also selected.

Tensorflow doesn't have access to libd3d12.so file:

2022-08-18 12:29:39.540717: >tensorflow/stream_executor/platform/default/dso_loader.cc:108] Could not load dynamic library 'libdirectml.0de2b4431c6572ee74152a7ee0cd3fb1534e4a95.so'; dlerror: libd3d12.so: cannot open shared object file: No such file or directory

Here is an article solving this issue: https://nnt339es.hatenablog.com/entry/2022/07/31/045059

Shortly said, use this line instead:

docker run -it --rm --device /dev/dxg --mount type=bind,src=/usr/lib/wsl,dst=/usr/lib/wsl -e LD_LIBRARY_PATH=/usr/lib/wsl/lib python:3.9.10

I'm new to Helm and my first task was to recreate a simple pipeline. This pipeline is just:

PostgreSQL -> Spark, with ELK monitoring the instances.

Someone mentioned I may be able to combine all of these into a single Helm chart; such that when I run the Helm chart it spins up PostgreSQL, Spark, and ELK. Is there any advantage to this? Before I attempt to do this, is it a best practice or would it be better to keep each one separate?

You can use a docker update. ( https://docs.docker.com/engine/reference/commandline/update/ ).

docker update --restart always /.

Not sure about removing the --rm flag, though

docker.io/library/$IMAGE:$TAG

The problem here is simple the right syntax for ctr isn't docker.io/alpine:latest but docker.io/library/alpine:latest that should now work with --creds "evancarroll:$TOKEN" too.

ctr images pull docker.io/library/alpine:latest

IRC logs

Thanks goes out to larks and ada on IRC #docker for helping out with this,

larsks> EvanCarroll: you probably need to include the tag there (ctr images pull docker.io/library/alpine:latest). The /library is there because that's the actual path to the image repository. There's some magic somewhere that transforms docker.io/alpine into docker.io/library/alpine; I don't know if that's client side or server side; ada will know much more about that than I do.

And thanks to https://github.com/distribution/distribution/blob/main/reference/normalize.go#L106 , and clarifying

library/ is the namespace for all the top-level images on dockerhub with docker, that namespace is implied if you leave off the registry & namespace part of the tag : docker pull alpine == ctr images pull docker.io/library/alpine

What is the difference between testing in the context of Continuous Integration pipeline vs testing in context of Continuous Testing pipeline? The definition of testing is a bit blurred to me in the context of CT pipeline.

An example, I understand testing in CI where a Unit Test is executed on a Pull Request - personally I'd defined it as a Continuous Testing since I continuously test incoming code however, this practice is known as CI. Then, what is CT then? Am I only one confusing CI for CT?

When I run commands under k3s kubectl, I get

$ k3s kubectl version
WARN[0000] Unable to read /etc/rancher/k3s/k3s.yaml, please start server with --write-kubeconfig-mode to modify kube config permissions 
error: error loading config file "/etc/rancher/k3s/k3s.yaml" : open /etc/rancher/k3s/k3s.yaml: permission denied

How should I resolve this? Should I change the permissions of /etc/rancher/k3s/k3s.yaml