Generate (template) Dockerfiles from one source for maintainability #4181

New Issue

Closed

opened 2026-03-07 19:32:27 -06:00 by GiteaMirror · 1 comment

GiteaMirror commented 2026-03-07 19:32:27 -06:00

Owner

Copy Link

Originally created by @ypid on GitHub (Dec 28, 2019).

Hi,

because of #784 I would now need to update all Dockerfiles. Do I miss something or are you really making changes to all of them manually? May I suggest a trick like I used for Hashbang OS:

https://github.com/hashbang/aosp-build/blob/master/config/container/Dockerfile
https://github.com/hashbang/aosp-build/blob/master/config/container/render_template

Originally created by @ypid on GitHub (Dec 28, 2019). Hi, because of #784 I would now need to update all Dockerfiles. Do I miss something or are you really making changes to all of them manually? May I suggest a trick like I used for Hashbang OS: https://github.com/hashbang/aosp-build/blob/master/config/container/Dockerfile https://github.com/hashbang/aosp-build/blob/master/config/container/render_template

GiteaMirror closed this issue 2026-03-07 19:32:27 -06:00

GiteaMirror commented 2026-03-07 19:32:28 -06:00

Author

Owner

Copy Link

@dani-garcia commented on GitHub (Dec 28, 2019):

At the moment all changes are made by hand, but you are right, it might not be a bad idea to use a template for each architecture, because the [sqlite, mysql, postgres] selection is basically the same outside dependencies and the cargo features.

It might be harder to do it between architectures, as the changes are bigger there, but then again maybe just unifying the database selection is good enough.

Your example sounds good, with one small detail: we'd have to store both the template and the rendered output in the repo to make docker hub work.

@dani-garcia commented on GitHub (Dec 28, 2019): At the moment all changes are made by hand, but you are right, it might not be a bad idea to use a template for each architecture, because the [sqlite, mysql, postgres] selection is basically the same outside dependencies and the cargo features. It might be harder to do it between architectures, as the changes are bigger there, but then again maybe just unifying the database selection is good enough. Your example sounds good, with one small detail: we'd have to store both the template and the rendered output in the repo to make docker hub work.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

cached-config-operations

test_dylint

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels

better for forum

bug

documentation

duplicate

enhancement

future Vault

good first issue

help wanted

low priority

notes

pull-request

Mirrored from GitHub Pull Request

question

SSO

Third party

troubleshooting

wontfix

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#4181