Closed japtain-cack closed 3 years ago
LGTM, but can you add example pillars to pillar.example
file. And update commit message to say "feat(compose-ng): devices support" so that Lint check passes. thanks
Yeah, and actually I jumped the gun on the PR. There is an issue. I'll fix tomorrow though.
Should I add a new container as an example or add the devices key to an existing one?
Whichever you prefer to be honest. thanks
On Thu, Dec 17, 2020 at 9:48 PM Nathan Snow notifications@github.com wrote:
Should I add a new container as an example or add the devices key to an existing one?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/saltstack-formulas/docker-formula/pull/269#issuecomment-747722180, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFUUQVAQUX5U3O7IRSYKWLSVJ4CNANCNFSM4U7HE6TA .
Added pillar example
Oops, wrong account. That was my comment just above.
@japtain-cack The CI is finally running again and it's showing us that this is failing the pre-commit
checks, specifically for yamllint
.
https://gitlab.com/saltstack-formulas/docker-formula/-/jobs/921902322#L158
Check YAML syntax with yamllint..........................................Failed - hook id: yamllint - duration: 0.89s - exit code: 2 ./pillar.example 167:14 warning truthy value should be one of [false, true] (truthy) 168:21 warning truthy value should be one of [false, true] (truthy) ./test/salt/pillar/archive.sls 167:14 warning truthy value should be one of [false, true] (truthy) 168:21 warning truthy value should be one of [false, true] (truthy)
True
and False
should use their lowercase equivalents.While you haven't touched ./test/salt/pillar/archive.sls
in this PR, it probably squeezed through when Travis CI stopped working. Would you mind adding that fix to this PR as well?
I merged https://github.com/saltstack-formulas/docker-formula/pull/270, thanks. Please get GitLab CI (funny to say that) working and all should be good. I doubt CI supports arm64?
Ok, I think I have all the tests passing now. Let me know if I should do anything else.
Ok, I think I have all the tests passing now. Let me know if I should do anything else.
Thanks @japtain-cack, CI tests passing so all looks good -- merged.
I merged #270, thanks. Please get GitLab CI (funny to say that) working and all should be good. I doubt CI supports arm64?
@noelmcloughlin This formulas was one of 4 out of 95 that I couldn't get working properly in GitLab CI. We're currently only running all of the pre-flight checks. Perhaps the arm64
has something to do with it? In any case, there is some work being done with GitHub Actions as well, so we can explore that avenue at some time in the future, hopefully.
:tada: This PR is included in version 1.1.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
@myii 91/95 is impressive. well done. Some people are running this formula on Rasberry Pi so #270 was arch64. I remember fixing up Travis CI on this formula a while back and wondering if the platform should be changed to vagrant so that containers
and swarm
and compose
could be tested properly. But I done what I could on driver: docker. Does docker run on docker?
I remember fixing up Travis CI on this formula a while back and wondering if the platform should be changed to vagrant so that
containers
andswarm
andcompose
could be tested properly.
@noelmcloughlin Vagrant-based testing (using GitHub Actions) is probably the way to go for this formula. We've got some (Windows) examples:
Obviously, would need to use Linux platforms!
But I done what I could on driver: docker. Does docker run on docker?
Yes, we're using dind
(Docker-in-Docker) in GitLab CI:
The problem is that this formula would require Docker-in-Docker-in-Docker(!), which I wouldn't expect to work too well:
myii/ssf-dind-ruby:2.7.1-r3
-- a customised dind
image (with Ruby installed) to run our pre-salted images in
saltimages/salt-master-py3:debian-10
) -- spun up by KitchenTo be honest, even Travis CI was struggling with that and not all of the states could be run in that setup.
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?No.
Related issues and/or pull requests
Describe the changes you're proposing
This adds support for devices. List of host devices to expose within the container. Can be expressed as a comma-separated list or a YAML list.
Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context