Time for the yearly barrage of “Setup CI”…“Fix CI” commits.
That is my experience with basically every CI service out there.
Time for the yearly barrage of “Setup CI”…“Fix CI” commits.
That is my experience with basically every CI service out there.
Never tried that, though a quick search got me this: https://superuser.com/questions/1471937/how-can-i-add-a-bcd-boot-entry-for-linux-in-windows-boot-manager-in-efi
Windows will not boot with this method. By renaming the file back to bootmgfw.efi windows will boot again but now linux won’t boot. There is no clean solution, other than switch to different computer that doesn’t have this issue. Because of issues like this I don’t recommend dual booting. Installing only Windows or only Linux is more manageable for not-tech-savvy people.
In windows EFI partition, there will be an EFI/Microsoft/bootmgfw.efi file, I usually rename it to bootmgfw.efi.bak and that allows grub to load.
I have observed that many laptops are hard-coded to boot windows whenever possible. Even with windows bootentry missing, firmware will skip Grub set to first priority and start windows. Only way to make them start Grub is to rename bootmgfw.efi to a different name.
Testcontainers uses ‘ryuk’ to clean up containers and it needs docker socket mounted within its container to work. So if you had any hardening config that prevents the docker socket access within a container e.g user namespace or SELinux then Testcontainers doesn’t work.
And I think it would be nice if Testcontainers ‘just worked’ with Podman without any additional steps.
Nothing else. Though docker socket issue was important enough.
You have to practice switching between neovim and other editors.
You have forgotten how to use a normal editor. I am not making it up, it is a real phenomenon. Similar to when SmarterEveryDay learned to ride a backwards bicycle he forgot how to ride a normal bicycle and essentially had to re-learn it. You have to re-learn how to use a normal editor.
It wants you to put dummy details as fast as you can.
It is a game, but it might also be a card grabber.
I did not make this, and you’re supposed to put dummy details there. Don’t put actual credit card information.
Thanks man, my brain was short-circuited on Testcontainers so I couldn’t write better. Also I am stealing the title.
I don’t get it, how would a database container run your unit tests? And unless you know some secret option to stop the database after, say, it is idle for a few seconds, it will continue running.
The purpose is to test database dependent code by spinning up a real database and run your code against that.
For me the value of podman is how easily it works without root. Just install and run, no need for sudo or adding myself to docker group.
I use it for testing and dev work, not for running any services.
It’s the same picture.
Yes it is the ratings on winehq, https://appdb.winehq.org/
And yes, an average user probably going to fire a game, figure out it is not working, and promptly go back to windows, which makes that data less accurate, but what can we do about it?
The left axis is total number of ratings of each type (Garbage, Bronze, Silver, Gold, Platinum) in a given month (not per app). For example for month 2016-07
there were
"Garbage" => 22
"Bronze" => 14
"Silver" => 13
"Gold" => 55
"Platinum" => 61
On right side is the average rating. So if I assign values to each rating:
"Garbage" => 1
"Bronze" => 2
"Silver" => 3
"Gold" => 4
"Platinum" => 5
I can get an average rating, which will be between 1 to 5.
((22*1) + (14*2) + (13*3) + (55*4) + (61*5)) / (22 + 14 + 13 + 55 + 61)
~= 3.721
We test our code locally, but we cannot test the workflow. By definition, testing the workflow has to be done on a CI-like system.
There is nektos/act for running github actions locally, it works for simple cases. There still are many differences between act and github actions.
It might be possible for a CI to define workflow steps using Containerfile/Dockerfile. Such workflows would be reproducible locally.