Archive This Repo and Forward Guidance
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- docker
- 領域
- devops
調査の方向性
ファイル、テスト、エントリーポイントのいずれも指定されていません。まず、リンクされた告知とリポジトリのイメージメンテナンスのコンテキストを確認し、その後、バージョンの整合性、ランタイムイメージ、ブランディング、アーカイブに関する問題を解決してください。合意されたプロジェクトの方向性と、それに対応するリポジトリの変更が揃えば完了です。
索引モデルが issue の本文から書いたものです。
説明
Summary of the new feature / enhancement
CC @sdwheeler @StevenBucher98 @mgreenegit
With the announcement of https://github.com/PowerShell/Announcements/issues/75 that the dotnet SDK docker is now the official PowerShell image, this repo should be archived so as not to confuse users that this may be under active development.
There are some unanswered questions needed, since the announcements has locked discussion:
Version Alignment and Identification
PowerShell releases do not align neatly with .NET SDK releases, especially recently with PowerShell releases lagging months after new .NET versions. When the PowerShell team does a security release e.g. 7.4.1, how are we to know and track what image that release will be available in? What is going to be the assurance on lead time, is the .NET SDK team willing to rebuild their images the moment those new powershell releases come out, or do they lag to when the .NET SDK revision gets bumped? All of these are concerns about maintaining security and update consistency in an environment. Sure we can always add on a layer to install the newer version ourselves, but if the whole point is for this to be a supported solution, it has to provide the same kind of expected lifecycle support.
I would recommend the team at least maintain a powershell docker tag that ties releases to SDK image hashes. The team will not be doing any building of containers, merely linking the appropriate image hashes so people can still track mcr.microsoft.com/powershell appropriately.
Runtime Images
The SDK image is focused on development, and is heavyweight. It is not a good base environment to run as a runtime powershell container, especially from an attack surface, image size, and supply chain perspective (as good as the SDK supply chain is). The .NET team provides distroless images based on Azure Linux and Dotnet Chiseled that are perfect for this. Ideally the team would provide images similar to what I provide at https://github.com/JustinGrote/PowerShell-Containers/pkgs/container/powershell but I understand with resource constraints if this must remain a community offering.
Again, I think this is a good forward approach and the reasoning makes sense, but I feel there needs to be a bit more done to maintain the branding of the container images, and enable Powershell to continue to thrive in a container world as a competitive offering alongside python, etc.
- 主要言語
- Dockerfile
- スター
- 449
- フォーク
- 158
- 平均マージ
- 3日 10時間
- マージ済み PR(30日)
- 1
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
PowerShell/PowerShell-Docker のほかの issue
-
Git オープンIssue-Enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
PowerShell/PowerShell-Docker#857 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
PowerShell/PowerShell-Docker#856 · コメント 2 件 · リアクション 1 件 ·
-
Issue-Enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 48/100
PowerShell/PowerShell-Docker#854 ·
-
Issue-Enhancement
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
PowerShell/PowerShell-Docker#851 · コメント 2 件 · リアクション 2 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 28/100
PowerShell/PowerShell-Docker#847 ·
PowerShell/PowerShell-Docker の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
Azure/azure-functions-docker#1257 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
conda-forge/vowpalwabbit-feedstock#104 · コメント 1 件 · リアクション 1 件 ·
-
good-start
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
deploy.sh hardcodes --dest while components.conf advertises WITH_PROXY_CA_BUNDLE as env-overridable オープンarea:proxy bug security severity:low track:open-source
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
components-web-app/docs#73 ·