build: install automake 1.16.5 from source in dev container

[yutaro-sakamoto]

Summary / 概要

• Install automake 1.16.5 from source instead of using the dnf package to ensure a consistent version across environments
• Add wget package for downloading automake source
• Fix hadolint warning by adding DL3003 ignore directive
• Add automake version check to CI workflow

---

• dnfパッケージではなく、環境間で一貫したバージョンを確保するためにautomake 1.16.5をソースからインストール
• automakeソースのダウンロードのためwgetパッケージを追加
• DL3003 ignore指令を追加してhadolintの警告を修正
• CIワークフローにautomakeバージョンチェックを追加

Test plan / テスト方法

• Verify dev container builds successfully with automake 1.16.5
• Check automake --version outputs 1.16.5 in the container
• CI workflow validates the automake installation

---

• automake 1.16.5で開発コンテナが正常にビルドされることを確認
• コンテナ内でautomake --versionが1.16.5を出力することを確認
• CIワークフローでautomakeのインストールを検証

[Copilot]

Pull request overview

This PR updates the dev container to install automake 1.16.5 from source rather than using the dnf package manager, ensuring a consistent version across development environments. The change addresses version consistency concerns while adding verification through CI.

Changes:

• Replace dnf-based automake installation with source-based installation of version 1.16.5
• Add wget package for downloading automake source tarball
• Add automake version verification to CI workflow

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.devcontainer/Dockerfile	Removes automake from dnf packages, adds wget, and implements source-based installation of automake 1.16.5 with build steps and cleanup
.github/workflows/check-dev-container.yml	Adds automake version check to verify the installation in CI

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The DL3003 hadolint rule warns against using 'cd' in a RUN instruction instead of WORKDIR. While the current suppression allows the build to work, using WORKDIR would be more aligned with Docker best practices and make directory changes more explicit.

Consider refactoring the automake installation to use WORKDIR for better clarity and to follow Docker conventions, though this would require splitting the RUN instruction or accepting the additional layer.

Suggested change

	&& tar xzf automake-1.16.5.tar.gz \
	&& cd automake-1.16.5 \
	&& ./configure \
	&& make -j"$(nproc)" \
	&& make install \
	&& cd .. \
	&& rm -rf automake-1.16.5 automake-1.16.5.tar.gz
	&& tar xzf automake-1.16.5.tar.gz
	WORKDIR /automake-1.16.5
	RUN ./configure \
	&& make -j"$(nproc)" \
	&& make install \
	&& rm -rf /automake-1.16.5 /automake-1.16.5.tar.gz
	WORKDIR /

[Copilot]

This PR installs automake 1.16.5 from source in the dev container to ensure version consistency, but the static-analysis.yml workflow (line 27) still installs automake via dnf, which may result in a different version. This inconsistency could lead to build differences between the dev container and the CI environment.

For true consistency across environments as stated in the PR description, consider also updating static-analysis.yml to install the same automake version from source.

[Copilot]

This Dockerfile downloads and builds automake-1.16.5.tar.gz directly from https://ftp.gnu.org and executes its configure/make as root without any checksum or signature verification, which introduces a supply chain risk. If an attacker can compromise or MITM the download host, they can serve a malicious tarball that will be built and installed into the dev container, potentially exfiltrating source code or secrets from developers' environments. To reduce this risk, verify the archive's integrity (e.g., pinned checksum or signature) or rely on a trusted, managed package source instead of an ad-hoc wget+build step.