[REQUEST] A more streamlined approach to customising a Railway deployment
維護者通常 1 天內回覆
@cameri 已經在處理了。
開始於 2023年11月30日。
評估
這個 Issue 還沒有評估資料。
描述
Pledge
If this feature request is implemented or resolved to my satisfaction, I am willing to make a small monetary donation to support the continued development and independence of this project. Please let me know the wallet address or provide a Lightning invoice once the feature is complete.
Is your feature request related to a problem? Please describe.
I'm experiencing challenges with customising the Railway deployment in the current setup of the repository. Specifically the need to maintain custom versions of two files (Dockerfile.railwayapp and .railwayapp/settings.yaml) for my deployment needs. The current repository structure and update process (including CI/CD and lintcommit demands) make it cumbersome to maintain these customisations, especially when syncing with upstream changes. Each time there's an update, I find myself having to manually check and ensure that my customisations aren't overwritten, which is time-consuming and prone to errors.
Describe the solution you'd like
I would greatly appreciate a more streamlined approach to customising the Railway deployment. Ideally, a solution where specific files (in my case, Dockerfile.railwayapp and .railwayapp/settings.yaml) can be easily marked or configured to avoid automatic updates from the upstream repository. This would allow for more flexibility and ease in maintaining a custom setup without the risk of losing custom changes on syncing with upstream.
Describe alternatives you've considered
After reading a number of issues regarding Railway deployment, I have been able to successfully correct, customise and deploy a working, charging, instance, but future maintenance looks possibly daunting.
I've looked into various workarounds, including:
Manually monitoring the upstream repository for changes and selectively applying updates.
Attempting to use Git features like sparse checkout or branching strategies, but these are complex and not ideal for my level of familiarity with Git.
However, these alternatives are either too complex or too time-consuming for my needs.
Additional context
The ability to customise specific aspects of the deployment for platforms like Railway, is crucial to encourage a wider range of users who might wish to constrain the default wide-open settings. Simplifying this process would not only help me but potentially benefit many others in the community facing similar challenges.
- 主要語言
- TypeScript
- 星號
- 829
- 分支
- 234
- 平均合併
- 2 天 10 小時
- 30 天內合併 PR
- 24
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
cameri/nostream 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 45/100
維護者通常 1 天內回覆
-
feat(nip77): advertise NIP-77 in NIP-11 and expose its settings in the admin console可能已有人在做 @Priyanshubhartistm 今天認領。 未關閉enhancement
cameri/nostream#819 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
feat(nip77): NEG-OPEN/NEG-MSG/NEG-CLOSE wire protocol for the PostgreSQL backend可能已有人在做 @Priyanshubhartistm 今天認領。 未關閉enhancement
cameri/nostream#817 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
[Admin Console] Ops visibility panels (mirror, workers, NIP-05, storage)可能已有人在做 @Ferryx349 今天認領。 未關閉Admin Console enhancement
cameri/nostream#816 · 已指派 1 人 ·
維護者通常 1 天內回覆
相似的 Issue
-
status: needs-triage
難度 2/5 1-3 小時 新手友好度 83/100
a2ui-project/a2ui#3158 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
hemilabs/ui-monorepo#2475 ·
維護者通常 1 天內回覆
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難度 1/5 1 小時以內 新手友好度 82/100
lingdojo/kana-dojo#32279 · 1 則留言 · 5 個 reaction ·
維護者通常 1 天內回覆
-
code-quality refactoring
難度 2/5 1-3 小時 新手友好度 77/100
github/gh-aw-firewall#9879 ·
維護者通常 1 天內回覆
-
[Bug]: Arrow-key cursor movement in combined diff view doesn't scroll to keep the cursor visible未關閉os:macos
難度 2/5 1-3 小時 新手友好度 64/100
維護者通常 1 天內回覆