8:38 a.m.
On Sep 11, Tomasz bla Fortuna wrote:
> I'll try explain the current workflows I use while working on
DebOps, both
> when creating new roles and when updating existing ones.
Very good description for the docs indeed. ;)
I suppose, but this will change, and would need to be written more from
a contributor perspective. Will do, eventually. :)
Summarizing from my point of view:
- You are, along ypid, pretty much the only persistent devs in this
project.
- And you both agreed that merging will help you work with it.
(as long as notifications / templates are done well)
- If it helps you - most other users should be pragmatically happy
about it too.
So I believe you should go with it.
Great. I'm already resolving old PRs (32 left) and issues (288 left) in the
GitHub repositories.
Things I would consider:
- The roles that need to work separately should still be tested
separately after the merge to maintain that status.
Dependencies like to creep in.
Currently that's the only way the tests are done, but that is a
subject to change eventually I guess.
Of course. Each role will still be tested separately as well as in interesting
groups. In fact, the GitLab test pipeline will have a few steps - basic
Ansible syntax check + documentation check, then some base DebOps roles, then
all of the rest of the roles, then the main playbook. Hopefully the order will
be that so the easy to spot issues will be found out before heavy tests.
- I believe the tooling should be able to use external roles, not
included in the main repo with ease. That way you can handle
maintainers of external roles who would:
- Use debops normally,
- develop locally their own role,
- publish in on github and letting it stabilize before including
directly in debops. (such role might be even alternative approach
to postfix which would never get included in fact)
- it would allow a user to include a number of external roles easily
and keep them updated.
(Possibly some glue code would have to be generated (including not
only all.yml but also external.yml which would have to be left out of
git but generated after clone? According to docs in 2.4 include is
deprecated and there are some ways to do dynamic includes)
The glue code is basically the 'debops' scripts were meant to be, and this of
course stays. I'll need to look at that dynamic includes, might be worth it.
Cheers,
Maciej
2409
days inactive
2409
days old
0 comments
1 participants
participants (1)
-
Maciej Delmanowski