I am trying to install the github-cli-2.20.2-r0 on Alpine Linux v3.17 running on WSL-2
I have the following repositories on my system:
cat /etc/apk/repositories
http://dl-cdn.alpinelinux.org/alpine/latest-stable/main
http://dl-cdn.alpinelinux.org/alpine/latest-stable/community
http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
http://dl-cdn.alpinelinux.org/alpine/edge/testing
I did an apk search for the githb cli
apk search github
foliate-2.6.4-r1
github-cli-2.20.2-r0
github-cli-zsh-completion-2.20.2-r0
py3-pygithub-1.57-r0
github-cli-bash-completion-2.20.2-r0
tootle-1.0-r2
github-cli-doc-2.20.2-r0
Then tried an install
sudo apk add github-cli-2.20.2-r0
ERROR: unable to select packages:
github-cli-2.20.2-r0 (no such package):
required by: world[github-cli-2.20.2-r0]
What am I doing wrong?
Removing the version worked for me:
sudo apk add github-cli
I am following the Reduce your CI cost using Docker to run local tests article and managed to run my tests inside a Ubuntu docker container. However, I have one test which fails after about 10 minutes of running. Here is the error I see:
# flutter test test/lib/mobile/services/sync/sync_service_test.dart
12:25 +0 -1: apiSync It should throw an exception if the sync fails [E]
TimeoutException after 0:10:00.000000: Test timed out after 10 minutes.
dart:isolate _RawReceivePortImpl._handleMessage
However, this test runs fine in macOS (my machine and in Bitrise CI).
To help resolve this issue, I am trying to find a way to debug this test. Is there a way I can remotely debug a test running inside this Docker container?
This is a copy of my modified Dockerfile:
# Need to match the version of Linux your CI is running on
FROM ubuntu:20.04
# Prerequisites
ARG DEBIAN_FRONTEND=noninteractive
ENV TZ=Europe/Paris
RUN apt update && apt install -y curl git unzip xz-utils zip libglu1-mesa openjdk-8-jdk wget libsqlite3-dev
WORKDIR /home/developer
# Download Flutter SDK
ARG flutter_version
RUN git clone https://github.com/flutter/flutter.git -b ${flutter_version}
ENV PATH "$PATH:/home/developer/flutter/bin"
COPY pubspec.* /home/developer/project/
WORKDIR /home/developer/project
RUN flutter pub get
COPY *.yaml *.json /home/developer/project/
COPY android /home/developer/project/android
COPY assets /home/developer/project/assets
COPY doc /home/developer/project/doc
COPY docker /home/developer/project/docker
COPY ios /home/developer/project/ios
COPY lib /home/developer/project/lib
COPY macos /home/developer/project/macos
COPY scripts /home/developer/project/scripts
COPY test /home/developer/project/test
COPY test_environment /home/developer/project/test_environment
COPY tool /home/developer/project/tool
COPY web /home/developer/project/web
# Run basic check to download Dark SDK
RUN flutter doctor
I would like to know the possibility of remote debugging rather than trying to solve the issue for this particular test.
Thanks in advance 🙏 !!!
I am running 90 microservices in openshift and few of the services are in CrashLoopBackOff and logs showing the following error message.
Error:
OC logs -f :
"standard_init_linux.go:219: exec user process caused: no such file or directory"
OC Describe:
Is there an issue with the image because describe output shows:
"Container image "IMAGE_TAG" already present on machine"
Due to the fact that there is lack of information -
it is impossible to say exactly where the problem is.
I have found some similar errors.
Here is one of the best solutions that matches description of your problem:
Here the key to solve the problem was replacing the aronautica crate via rust-argon2 and modifying the Dockerfile:
FROM rust AS build
WORKDIR /usr/src
RUN apt-get update && apt-get upgrade -y && apt-get install -y build-essential git clang llvm-dev libclang-dev libssl-dev pkg-config libpq-dev brotli
RUN USER=root cargo new loxe-api WORKDIR /usr/src/loxe-api COPY
Cargo.toml Cargo.lock ./ COPY data ./data COPY migrations ./migrations
RUN cargo build --release
# Copy the source and build the application. COPY src ./src ENV PKG_CONFIG_ALLOW_CROSS=1 ENV
OPENSSL_INCLUDE_DIR="/usr/include/openssl" RUN cargo install --path .
FROM debian:buster-slim COPY --from=build
/usr/local/cargo/bin/loxe-api .
# standard env COPY .env ./.env COPY data ./data COPY migrations ./migrations RUN apt-get update && apt-get install -y libssl-dev
pkg-config libpq-dev brotli CMD ["/loxe-api"] ```
See also this similar issues:
second one
third one
So recently (5th September) the Alpine Linux package repo was updated to postgresql-client 12.4
I'm referencing version 12.3 in my Dockerfile (apk add postgresql-client=~12.3). Is it not possible to install that version now?
I'd like to update on my time and terms, why should I be forced to update now? Is there another repository I can add to use the older version?
Thanks
Unfortunately, Alpine packages are always updated in place to the latest version, and older versions are discarded. This could be painful, indeed...
Usually, when a package is updated, it's updated with all Alpine distro versions that it's compatible to. For example, postgresql-client was bumped to 12.4-r0 on edge, v3.12 and v3.11, but on Alpine v3.10 repos you'll still find 11.9-r0. In case this was enough, the old version could be installed from the desired repository, as long as it lasts, using:
apk add postgresql-client=11.9-r0 --repository=http://dl-cdn.alpinelinux.org/alpine/v3.10/main
However, since 12.3 doesn't live in the official Alpine repositories anymore, you could rely on an external Docker image, instead.
Luckily, the postgres official images has version tags, and you can find the desired Alpine image for 12.3:
$ wget -q https://registry.hub.docker.com/v1/repositories/postgres/tags -O - | jq -r '.[].name' | grep 12.3
12.3
12.3-alpine
Therefore, you can use FROM:postgres:12.3-alpine to get the desired version from.
In tougher cases, where the Alpine package version is updated, and couldn't be found in other images, the only resort may be building from source.
for example; the latest dnsmasq version ins 2.84-r0 at now, if you install 2.83-r0, will:
$ docker run --rm -ti alpine:3.13
$ apk add 'dnsmasq-dnssec==2.83-r0'
fetch https://mirrors.aliyun.com/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://mirrors.aliyun.com/alpine/v3.13/community/x86_64/APKINDEX.tar.gz
ERROR: unable to select packages:
dnsmasq-dnssec-2.84-r0:
breaks: world[dnsmasq-dnssec=2.83-r0]
The best thing you can achieve is using repositories of the earlier releases, at the websiete https://pkgs.alpinelinux.org/packages to search the old version, will find 2.83-r0 in https://pkgs.alpinelinux.org/packages?name=dnsmasq&branch=v3.12.
so add the old repo
$ echo 'http://dl-cdn.alpinelinux.org/alpine/v3.12/main' >> /etc/apk/repositories
$ apk add 'dnsmasq-dnssec==2.83-r0'
fetch http://mirrors.aliyun.com/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.aliyun.com/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/3) Installing gmp (6.2.0-r0)
(2/3) Installing nettle (3.5.1-r1)
(3/3) Installing dnsmasq-dnssec (2.83-r0)
Executing dnsmasq-dnssec-2.83-r0.pre-install
Executing busybox-1.31.1-r16.trigger
OK: 7 MiB in 17 packages
Another solution based on the answer of #valiano.
For upgrading postgresql to a newer version, it is recommended to use the higher version pg_dump binaries. But how to get these into your image?
This works for me:
Dockerfile:
ARG VERSION=10
ARG UPGRADE_VERSION=11
ARG TYPE
###############################################################
# Normal server
###############################################################
FROM postgres:${VERSION}-alpine AS server
RUN apk update \
&& apk add --upgrade apk-tools \
&& apk upgrade --available
COPY /rootfs/ /
###############################################################
# Upgrade version with upgrade executables
###############################################################
FROM postgres:${UPGRADE_VERSION}-alpine AS upgrade_version
RUN apk update \
&& apk add --upgrade apk-tools \
&& apk upgrade --available
###############################################################
# Add postgresql upgrade client executables to upgrade_server_layer
###############################################################
FROM server AS upgrade_server
RUN mkdir -p /usr/local/postgresql/upgrade
COPY --from=upgrade_version /usr/local/bin/pg* /usr/local/postgresql/upgrade/
###############################################################
# Final version
###############################################################
FROM ${TYPE}server AS final
Then build your normal server as:
docker build --build-arg TYPE= --build-arg VERSION=11 --build-arg UPGRADE_VERSION=12 -t my_normal_server:11 .
And a server with upgrade binaries, to make the dumpfile:
docker build --build-arg TYPE=upgrade_ --build-arg VERSION=10 --build-arg UPGRADE_VERSION=11 -t my_upgrade_server:10 .
Upgrade scenario if current version is postgresql 10 and you want to upgrade to 11:
Build an upgrade version and a normal version.
Stop the postgresql 10 container and replace it with the my_upgrade_version:10
Create a dumpfile with the /usr/local/postgresql/upgrade/pg_dump.
Create a new postgresql 11 container with my_normal_version:11 with access to the dumpfile and use pg_restore to restore the created dumpfile.
About making a dry single-point-of-entry for fixed package versions:
I use the following method, where I have an .env file where I store the PG major and minor version. I only need to update the .env-file entry with preferred version numbers and rebuild my images to upgrade the Postgres.
As long as the package is present with the corresponding version in the dockerhub and the PG version itself isn't deprecated by the alpine repositories or sth:
Step 1: Specify the PG version in .env file as single point of entry:
PG_MAJOR_VERSION=14
PG_MINOR_VERSION=5
Step 2: Reference the db-package inside the docker-compose:
services:
db:
image: postgres:${PG_MAJOR_VERSION}.${PG_MINOR_VERSION}-alpine
Step 3: Use the variables inside the Dockerfile itself if needed:
ARG RUBY_VERSION
ARG DISTRO_NAME
FROM ruby:${RUBY_VERSION}-${DISTRO_NAME}
# Need to define the args again:
ARG DISTRO_NAME
ARG PG_MAJOR_VERSION
RUN apk add --update build-base bash bash-completion libffi-dev tzdata postgresql$PG_MAJOR_VERSION-client postgresql$PG_MAJOR_VERSION-dev nodejs npm yarn
NB! The FROM clause loses the ARG-variables defined before it. Therefore if you need them later then you need to define them again after the FROM-clause. This issue is described in more detail in this Github issue
Depending on the packages you wish to install you can specify the minor version or other suffixes as needed (for ex for postgresql15-client-15.1-r0 and postgresql15-dev-15.1-r0: package etc)
I have an operating environment that is Alpine linux only and I need to install VS Code. How can VS Code be run on Alpine Linux?
Dockerfile:
FROM node:14.19.0-alpine
RUN set -x \
&& sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories \
&& apk upgrade \
&& apk --no-cache add alpine-sdk bash libstdc++ libc6-compat \
&& npm config set python python3
RUN git clone --recursive https://github.com/cdr/code-server.git
RUN cd code-server
RUN yarn global add code-server
ENV PASSWORD=changeme
ENTRYPOINT code-server --bind-addr 0:8443
Commands:
docker build . -t vscode
docker run -d -e PASSWORD=111111 -p8443:8443 vscode:latest
http://hostname:8443
Download it in Flatpak repos, it will run natively in a Gnome SDK environment.
Use a self-hosted environment such as Theia (https://www.theia-ide.org/index.html) or coder-editor (https://coder.com/). I've never tried them, I use the Flatpak one, but they seem interesting (you can "build" your osn editor in a Node environment).
Apologies for necrobump, but as what Marco suggested, coder.com has moved to github
the software, code-server is quite litterally VSCode, as a web application, I have been using this for about half a year and it is quite well developed, Alpine support is still spotty but i recall getting a few releases to function well a while back when i ran Alpine as my main.