[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
- 平均合并
- 4 天 5 小时
- 30 天内合并 PR
- 22
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
cameri/nostream 的其他 Issue
-
validateSettings() doesn't validate rateLimits[].period — zero period silently degrades to a 1ms backoff hint可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
feat(nip77): negentropy reconciliation core for the PostgreSQL backend可能已有人在做 @Priyanshubhartistm 于 2 天前认领。 未关闭enhancement
cameri/nostream#801 · 已指派 1 人 ·
维护者通常 1 天内回复
-
feat(admin): bounded NIP-66 probe history and Network Health timeline可能已有人在做 @Ferryx349 于 2 天前认领。 未关闭Admin Console enhancement
cameri/nostream#800 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Store relay settings overrides in PostgreSQL (SETTINGS_BACKEND=db)可能已有人在做 @Ferryx349 于 36 天前认领。 未关闭enhancement
cameri/nostream#757 · 已指派 1 人 ·
维护者通常 1 天内回复
相似的 Issue
-
bug go
难度 2/5 1-3 小时 新手友好度 82/100
genkit-ai/genkit#6761 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
NousResearch/hermes-agent#136483 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 84/100
facioquo/stock-indicators-dotnet#2316 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
vercel-labs/skills#2460 ·
维护者通常 1 天内回复