mirror of https://github.com/docker/compose.git
Merge remote-tracking branch 'origin/main' into ecs-import
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
This commit is contained in:
Nicolas De Loof
commit
66e25937c6
|
|
@ -0,0 +1,71 @@
|
|||
<!--
|
||||
If you are reporting a new issue, make sure that we do not have any duplicates
|
||||
already open. You can ensure this by searching the issue list for this
|
||||
repository. If there is a duplicate, please close your issue and add a comment
|
||||
to the existing issue instead.
|
||||
|
||||
If you suspect your issue is a bug, please edit your issue description to
|
||||
include the BUG REPORT INFORMATION shown below. If you fail to provide this
|
||||
information within 7 days, we cannot debug your issue and will close it. We
|
||||
will, however, reopen it if you later provide the information.
|
||||
|
||||
For more information about reporting issues, see
|
||||
https://github.com/docker/compose-cli/blob/master/CONTRIBUTING.md#reporting-other-issues
|
||||
|
||||
---------------------------------------------------
|
||||
GENERAL SUPPORT INFORMATION
|
||||
---------------------------------------------------
|
||||
|
||||
The GitHub issue tracker is for bug reports and feature requests.
|
||||
General support can be found at the following locations:
|
||||
|
||||
- Docker Support Forums - https://forums.docker.com
|
||||
- Docker Community Slack - https://dockr.ly/community
|
||||
- Post a question on StackOverflow, using the Docker tag
|
||||
|
||||
---------------------------------------------------
|
||||
BUG REPORT INFORMATION
|
||||
---------------------------------------------------
|
||||
Use the commands below to provide key information from your environment:
|
||||
You do NOT have to include this information if this is a FEATURE REQUEST
|
||||
-->
|
||||
|
||||
**Description**
|
||||
|
||||
<!--
|
||||
Briefly describe the problem you are having in a few paragraphs.
|
||||
-->
|
||||
|
||||
**Steps to reproduce the issue:**
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
**Describe the results you received:**
|
||||
|
||||
|
||||
**Describe the results you expected:**
|
||||
|
||||
|
||||
**Additional information you deem important (e.g. issue happens only occasionally):**
|
||||
|
||||
**Output of `docker version`:**
|
||||
|
||||
```
|
||||
(paste your output here)
|
||||
```
|
||||
|
||||
**Output of `docker context show`:**
|
||||
You can also run `docker context inspect context-name` to give us more details but don't forget to remove sensitive content.
|
||||
|
||||
```
|
||||
(paste your output here)
|
||||
```
|
||||
|
||||
**Output of `docker info`:**
|
||||
|
||||
```
|
||||
(paste your output here)
|
||||
```
|
||||
|
||||
**Additional environment details (AWS ECS, Azure ACI, local, etc.):**
|
||||
|
|
@ -18,7 +18,7 @@ jobs:
|
|||
- name: Checkout code into the Go module directory
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- name: Validate license headers
|
||||
- name: Validate go-mod is up-to-date and license headers
|
||||
run: make validate
|
||||
|
||||
- name: Run golangci-lint
|
||||
|
|
|
|||
|
|
@ -0,0 +1,323 @@
|
|||
# Contributing to Docker
|
||||
|
||||
Want to hack on Docker? Awesome! We have a contributor's guide that explains
|
||||
[setting up a Docker development environment and the contribution
|
||||
process](https://docs.docker.com/opensource/project/who-written-for/).
|
||||
|
||||
This page contains information about reporting issues as well as some tips and
|
||||
guidelines useful to experienced open source contributors. Finally, make sure
|
||||
you read our [community guidelines](#docker-community-guidelines) before you
|
||||
start participating.
|
||||
|
||||
## Topics
|
||||
|
||||
* [Reporting Security Issues](#reporting-security-issues)
|
||||
* [Design and Cleanup Proposals](#design-and-cleanup-proposals)
|
||||
* [Reporting Issues](#reporting-other-issues)
|
||||
* [Quick Contribution Tips and Guidelines](#quick-contribution-tips-and-guidelines)
|
||||
* [Community Guidelines](#docker-community-guidelines)
|
||||
|
||||
## Reporting security issues
|
||||
|
||||
The Docker maintainers take security seriously. If you discover a security
|
||||
issue, please bring it to their attention right away!
|
||||
|
||||
Please **DO NOT** file a public issue, instead send your report privately to
|
||||
[security@docker.com](mailto:security@docker.com).
|
||||
|
||||
Security reports are greatly appreciated and we will publicly thank you for it.
|
||||
We also like to send gifts—if you're into Docker swag, make sure to let
|
||||
us know. We currently do not offer a paid security bounty program, but are not
|
||||
ruling it out in the future.
|
||||
|
||||
|
||||
## Reporting other issues
|
||||
|
||||
A great way to contribute to the project is to send a detailed report when you
|
||||
encounter an issue. We always appreciate a well-written, thorough bug report,
|
||||
and will thank you for it!
|
||||
|
||||
Check that [our issue database](https://github.com/docker/compose-cli/issues)
|
||||
doesn't already include that problem or suggestion before submitting an issue.
|
||||
If you find a match, you can use the "subscribe" button to get notified on
|
||||
updates. Do *not* leave random "+1" or "I have this too" comments, as they
|
||||
only clutter the discussion, and don't help to resolve it. However, if you
|
||||
have ways to reproduce the issue or have additional information that may help
|
||||
resolving the issue, please leave a comment.
|
||||
|
||||
When reporting issues, always include:
|
||||
|
||||
* The output of `docker version`.
|
||||
* The output of `docker context show`.
|
||||
* The output of `docker info`.
|
||||
|
||||
Also include the steps required to reproduce the problem if possible and
|
||||
applicable. This information will help us review and fix your issue faster.
|
||||
When sending lengthy log-files, consider posting them as a gist (https://gist.github.com).
|
||||
Don't forget to remove sensitive data from your logfiles before posting (you can
|
||||
replace those parts with "REDACTED").
|
||||
|
||||
## Quick contribution tips and guidelines
|
||||
|
||||
This section gives the experienced contributor some tips and guidelines.
|
||||
|
||||
### Pull requests are always welcome
|
||||
|
||||
Not sure if that typo is worth a pull request? Found a bug and know how to fix
|
||||
it? Do it! We will appreciate it. Any significant improvement should be
|
||||
documented as [a GitHub issue](https://github.com/docker/compose-cli/issues) before
|
||||
anybody starts working on it.
|
||||
|
||||
We are always thrilled to receive pull requests. We do our best to process them
|
||||
quickly. If your pull request is not accepted on the first try,
|
||||
don't get discouraged! Our contributor's guide explains [the review process we
|
||||
use for simple changes](https://docs.docker.com/opensource/workflow/make-a-contribution/).
|
||||
|
||||
### Talking to other Docker users and contributors
|
||||
|
||||
<table class="tg">
|
||||
<col width="45%">
|
||||
<col width="65%">
|
||||
<tr>
|
||||
<td>Forums</td>
|
||||
<td>
|
||||
A public forum for users to discuss questions and explore current design patterns and
|
||||
best practices about Docker and related projects in the Docker Ecosystem. To participate,
|
||||
just log in with your Docker Hub account on <a href="https://forums.docker.com" target="_blank">https://forums.docker.com</a>.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Community Slack</td>
|
||||
<td>
|
||||
The Docker Community has a dedicated Slack chat to discuss features and issues. You can sign-up <a href="https://community.docker.com/registrations/groups/4316" target="_blank">with this link</a>.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Twitter</td>
|
||||
<td>
|
||||
You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's Twitter feed</a>
|
||||
to get updates on our products. You can also tweet us questions or just
|
||||
share blogs or stories.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Stack Overflow</td>
|
||||
<td>
|
||||
Stack Overflow has over 17000 Docker questions listed. We regularly
|
||||
monitor <a href="https://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a>
|
||||
and so do many other knowledgeable Docker users.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
### Conventions
|
||||
|
||||
Fork the repository and make changes on your fork in a feature branch:
|
||||
|
||||
- If it's a bug fix branch, name it XXXX-something where XXXX is the number of
|
||||
the issue.
|
||||
- If it's a feature branch, create an enhancement issue to announce
|
||||
your intentions, and name it XXXX-something where XXXX is the number of the
|
||||
issue.
|
||||
|
||||
Submit unit tests for your changes. Go has a great test framework built in; use
|
||||
it! Take a look at existing tests for inspiration. [Run the full test
|
||||
suite](README.md) on your branch before
|
||||
submitting a pull request.
|
||||
|
||||
Write clean code. Universally formatted code promotes ease of writing, reading,
|
||||
and maintenance. Always run `gofmt -s -w file.go` on each changed file before
|
||||
committing your changes. Most editors have plug-ins that do this automatically.
|
||||
|
||||
Pull request descriptions should be as clear as possible and include a reference
|
||||
to all the issues that they address.
|
||||
|
||||
Commit messages must start with a capitalized and short summary (max. 50 chars)
|
||||
written in the imperative, followed by an optional, more detailed explanatory
|
||||
text which is separated from the summary by an empty line.
|
||||
|
||||
Code review comments may be added to your pull request. Discuss, then make the
|
||||
suggested modifications and push additional commits to your feature branch. Post
|
||||
a comment after pushing. New commits show up in the pull request automatically,
|
||||
but the reviewers are notified only when you comment.
|
||||
|
||||
Pull requests must be cleanly rebased on top of master without multiple branches
|
||||
mixed into the PR.
|
||||
|
||||
**Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
|
||||
feature branch to update your pull request rather than `merge master`.
|
||||
|
||||
Before you make a pull request, squash your commits into logical units of work
|
||||
using `git rebase -i` and `git push -f`. A logical unit of work is a consistent
|
||||
set of patches that should be reviewed together: for example, upgrading the
|
||||
version of a vendored dependency and taking advantage of its now available new
|
||||
feature constitute two separate units of work. Implementing a new function and
|
||||
calling it in another file constitute a single logical unit of work. The very
|
||||
high majority of submissions should have a single commit, so if in doubt: squash
|
||||
down to one.
|
||||
|
||||
After every commit, make sure the test suite passes. Include documentation
|
||||
changes in the same pull request so that a revert would remove all traces of
|
||||
the feature or fix.
|
||||
|
||||
Include an issue reference like `Closes #XXXX` or `Fixes #XXXX` in the pull request
|
||||
description that close an issue. Including references automatically closes the issue
|
||||
on a merge.
|
||||
|
||||
Please do not add yourself to the `AUTHORS` file, as it is regenerated regularly
|
||||
from the Git history.
|
||||
|
||||
Please see the [Coding Style](#coding-style) for further guidelines.
|
||||
|
||||
### Merge approval
|
||||
|
||||
Docker maintainers use LGTM (Looks Good To Me) in comments on the code review to
|
||||
indicate acceptance.
|
||||
|
||||
A change requires at least 2 LGTMs from the maintainers of each
|
||||
component affected.
|
||||
|
||||
For more details, see the [MAINTAINERS](MAINTAINERS) page.
|
||||
|
||||
### Sign your work
|
||||
|
||||
The sign-off is a simple line at the end of the explanation for the patch. Your
|
||||
signature certifies that you wrote the patch or otherwise have the right to pass
|
||||
it on as an open-source patch. The rules are pretty simple: if you can certify
|
||||
the below (from [developercertificate.org](http://developercertificate.org/)):
|
||||
|
||||
```
|
||||
Developer Certificate of Origin
|
||||
Version 1.1
|
||||
|
||||
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
|
||||
660 York Street, Suite 102,
|
||||
San Francisco, CA 94110 USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies of this
|
||||
license document, but changing it is not allowed.
|
||||
|
||||
Developer's Certificate of Origin 1.1
|
||||
|
||||
By making a contribution to this project, I certify that:
|
||||
|
||||
(a) The contribution was created in whole or in part by me and I
|
||||
have the right to submit it under the open source license
|
||||
indicated in the file; or
|
||||
|
||||
(b) The contribution is based upon previous work that, to the best
|
||||
of my knowledge, is covered under an appropriate open source
|
||||
license and I have the right under that license to submit that
|
||||
work with modifications, whether created in whole or in part
|
||||
by me, under the same open source license (unless I am
|
||||
permitted to submit under a different license), as indicated
|
||||
in the file; or
|
||||
|
||||
(c) The contribution was provided directly to me by some other
|
||||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
```
|
||||
|
||||
Then you just add a line to every git commit message:
|
||||
|
||||
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||
|
||||
Use your real name (sorry, no pseudonyms or anonymous contributions.)
|
||||
|
||||
If you set your `user.name` and `user.email` git configs, you can sign your
|
||||
commit automatically with `git commit -s`.
|
||||
|
||||
### How can I become a maintainer?
|
||||
|
||||
The procedures for adding new maintainers are explained in the
|
||||
global [MAINTAINERS](https://github.com/docker/opensource/blob/master/MAINTAINERS)
|
||||
file in the [https://github.com/docker/opensource/](https://github.com/docker/opensource/)
|
||||
repository.
|
||||
|
||||
Don't forget: being a maintainer is a time investment. Make sure you
|
||||
will have time to make yourself available. You don't have to be a
|
||||
maintainer to make a difference on the project!
|
||||
|
||||
## Docker community guidelines
|
||||
|
||||
We want to keep the Docker community awesome, growing and collaborative. We need
|
||||
your help to keep it that way. To help with this we've come up with some general
|
||||
guidelines for the community as a whole:
|
||||
|
||||
* Be nice: Be courteous, respectful and polite to fellow community members:
|
||||
no regional, racial, gender, or other abuse will be tolerated. We like
|
||||
nice people way better than mean ones!
|
||||
|
||||
* Encourage diversity and participation: Make everyone in our community feel
|
||||
welcome, regardless of their background and the extent of their
|
||||
contributions, and do everything possible to encourage participation in
|
||||
our community.
|
||||
|
||||
* Keep it legal: Basically, don't get us in trouble. Share only content that
|
||||
you own, do not share private or sensitive information, and don't break
|
||||
the law.
|
||||
|
||||
* Stay on topic: Make sure that you are posting to the correct channel and
|
||||
avoid off-topic discussions. Remember when you update an issue or respond
|
||||
to an email you are potentially sending to a large number of people. Please
|
||||
consider this before you update. Also remember that nobody likes spam.
|
||||
|
||||
* Don't send email to the maintainers: There's no need to send email to the
|
||||
maintainers to ask them to investigate an issue or to take a look at a
|
||||
pull request. Instead of sending an email, GitHub mentions should be
|
||||
used to ping maintainers to review a pull request, a proposal or an
|
||||
issue.
|
||||
|
||||
## Coding Style
|
||||
|
||||
Unless explicitly stated, we follow all coding guidelines from the Go
|
||||
community. While some of these standards may seem arbitrary, they somehow seem
|
||||
to result in a solid, consistent codebase.
|
||||
|
||||
It is possible that the code base does not currently comply with these
|
||||
guidelines. We are not looking for a massive PR that fixes this, since that
|
||||
goes against the spirit of the guidelines. All new contributions should make a
|
||||
best effort to clean up and make the code base better than they left it.
|
||||
Obviously, apply your best judgement. Remember, the goal here is to make the
|
||||
code base easier for humans to navigate and understand. Always keep that in
|
||||
mind when nudging others to comply.
|
||||
|
||||
The rules:
|
||||
|
||||
1. All code should be formatted with `gofmt -s`.
|
||||
2. All code should pass the default levels of
|
||||
[`golint`](https://github.com/golang/lint).
|
||||
3. All code should follow the guidelines covered in [Effective
|
||||
Go](http://golang.org/doc/effective_go.html) and [Go Code Review
|
||||
Comments](https://github.com/golang/go/wiki/CodeReviewComments).
|
||||
4. Comment the code. Tell us the why, the history and the context.
|
||||
5. Document _all_ declarations and methods, even private ones. Declare
|
||||
expectations, caveats and anything else that may be important. If a type
|
||||
gets exported, having the comments already there will ensure it's ready.
|
||||
6. Variable name length should be proportional to its context and no longer.
|
||||
`noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`.
|
||||
In practice, short methods will have short variable names and globals will
|
||||
have longer names.
|
||||
7. No underscores in package names. If you need a compound name, step back,
|
||||
and re-examine why you need a compound name. If you still think you need a
|
||||
compound name, lose the underscore.
|
||||
8. No utils or helpers packages. If a function is not general enough to
|
||||
warrant its own package, it has not been written generally enough to be a
|
||||
part of a util package. Just leave it unexported and well-documented.
|
||||
9. All tests should run with `go test` and outside tooling should not be
|
||||
required. No, we don't need another unit testing framework. Assertion
|
||||
packages are acceptable if they provide _real_ incremental value.
|
||||
10. Even though we call these "rules" above, they are actually just
|
||||
guidelines. Since you've read all the rules, you now know that.
|
||||
|
||||
If you are having trouble getting into the mood of idiomatic Go, we recommend
|
||||
reading through [Effective Go](https://golang.org/doc/effective_go.html). The
|
||||
[Go Blog](https://blog.golang.org) is also a great resource. Drinking the
|
||||
kool-aid is a lot easier than going thirsty.
|
||||
|
|
@ -93,3 +93,7 @@ RUN --mount=target=. \
|
|||
--mount=type=cache,target=/root/.cache/go-build \
|
||||
make -f builder.Makefile check-license-headers
|
||||
|
||||
FROM base as check-go-mod
|
||||
COPY . .
|
||||
RUN --mount=type=cache,target=/root/.cache/go-build \
|
||||
make -f builder.Makefile check-go-mod
|
||||
|
|
|
|||
|
|
@ -0,0 +1,80 @@
|
|||
# Docker maintainers file
|
||||
#
|
||||
# This file describes who runs the docker/app project and how.
|
||||
# This is a living document - if you see something out of date or missing, speak up!
|
||||
#
|
||||
# It is structured to be consumable by both humans and programs.
|
||||
# To extract its contents programmatically, use any TOML-compliant
|
||||
# parser.
|
||||
#
|
||||
# This file is compiled into the MAINTAINERS file in docker/opensource.
|
||||
#
|
||||
[Org]
|
||||
|
||||
[Org."Core maintainers"]
|
||||
|
||||
# The Core maintainers are the ghostbusters of the project: when there's a problem others
|
||||
# can't solve, they show up and fix it with bizarre devices and weaponry.
|
||||
# They have final say on technical implementation and coding style.
|
||||
# They are ultimately responsible for quality in all its forms: usability polish,
|
||||
# bugfixes, performance, stability, etc. When ownership can cleanly be passed to
|
||||
# a subsystem, they are responsible for doing so and holding the
|
||||
# subsystem maintainers accountable. If ownership is unclear, they are the de facto owners.
|
||||
|
||||
people = [
|
||||
"rumpl",
|
||||
"gtardif",
|
||||
"chris-chrone"
|
||||
]
|
||||
|
||||
[Org."Docs maintainers"]
|
||||
|
||||
# TODO Describe the docs maintainers role.
|
||||
|
||||
people = [
|
||||
"rumpl",
|
||||
"gtardif",
|
||||
"chris-chrone"
|
||||
]
|
||||
|
||||
[Org.Curators]
|
||||
|
||||
# The curators help ensure that incoming issues and pull requests are properly triaged and
|
||||
# that our various contribution and reviewing processes are respected. With their knowledge of
|
||||
# the repository activity, they can also guide contributors to relevant material or
|
||||
# discussions.
|
||||
#
|
||||
# They are neither code nor docs reviewers, so they are never expected to merge. They can
|
||||
# however:
|
||||
# - close an issue or pull request when it's an exact duplicate
|
||||
# - close an issue or pull request when it's inappropriate or off-topic
|
||||
|
||||
people = [
|
||||
"rumpl",
|
||||
"gtardif",
|
||||
"chris-chrone"
|
||||
]
|
||||
|
||||
[people]
|
||||
|
||||
# A reference list of all people associated with the project.
|
||||
# All other sections should refer to people by their canonical key
|
||||
# in the people section.
|
||||
|
||||
# ADD YOURSELF HERE IN ALPHABETICAL ORDER
|
||||
|
||||
[people.rumpl]
|
||||
Name = "Djordje Lukic"
|
||||
Email = "djordje.lukic@docker.com"
|
||||
GitHub = "rumpl"
|
||||
|
||||
[people.gtardif]
|
||||
Name = "Guillaume Tardif"
|
||||
Email = "guillaume.tardif@docker.com"
|
||||
GitHub = "gtardif"
|
||||
|
||||
[people.chris-crone]
|
||||
Name = "Christopher Crone"
|
||||
Email = "christopher.crone@docker.com"
|
||||
GitHub = "chris-crone"
|
||||
|
||||
11
Makefile
11
Makefile
|
|
@ -75,16 +75,21 @@ lint: ## run linter(s)
|
|||
serve: cli ## start server
|
||||
@./bin/docker serve --address unix:///tmp/backend.sock
|
||||
|
||||
moby-cli-link: ## create com.docker.cli symlink if does not already exist
|
||||
moby-cli-link: ## Create com.docker.cli symlink if does not already exist
|
||||
ln -s $(MOBY_DOCKER) /usr/local/bin/com.docker.cli
|
||||
|
||||
validate: ## check license header for all files
|
||||
validate-headers: ## Check license header for all files
|
||||
@docker build . --target check-license-headers
|
||||
|
||||
validate-go-mod: ## Validate go.mod and go.sum are up-to-date
|
||||
@docker build . --target check-go-mod
|
||||
|
||||
validate: validate-go-mod validate-headers ## Validate sources
|
||||
|
||||
help: ## Show help
|
||||
@echo Please specify a build target. The choices are:
|
||||
@grep -E '^[0-9a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'
|
||||
|
||||
FORCE:
|
||||
|
||||
.PHONY: all protos cli e2e-local cross test cache-clear lint serve classic-link help
|
||||
.PHONY: all validate protos cli e2e-local cross test cache-clear lint serve classic-link help
|
||||
|
|
|
|||
|
|
@ -49,7 +49,6 @@ const (
|
|||
singleContainerTag = "docker-single-container"
|
||||
composeContainerTag = "docker-compose-application"
|
||||
composeContainerSeparator = "_"
|
||||
statusUnknown = "Unknown"
|
||||
statusRunning = "Running"
|
||||
)
|
||||
|
||||
|
|
@ -170,38 +169,20 @@ func (cs *aciContainerService) List(ctx context.Context, all bool) ([]containers
|
|||
if *container.Name == convert.ComposeDNSSidecarName {
|
||||
continue
|
||||
}
|
||||
if !all && getStatus(container) != statusRunning {
|
||||
if !all && convert.GetStatus(container, group) != statusRunning {
|
||||
continue
|
||||
}
|
||||
containerID := *containerGroup.Name + composeContainerSeparator + *container.Name
|
||||
if _, ok := group.Tags[singleContainerTag]; ok {
|
||||
containerID = *containerGroup.Name
|
||||
}
|
||||
c := getContainer(containerID, group.IPAddress, container)
|
||||
c := convert.ContainerGroupToContainer(containerID, group, container)
|
||||
res = append(res, c)
|
||||
}
|
||||
}
|
||||
return res, nil
|
||||
}
|
||||
|
||||
func getContainer(containerID string, ipAddress *containerinstance.IPAddress, container containerinstance.Container) containers.Container {
|
||||
status := getStatus(container)
|
||||
return containers.Container{
|
||||
ID: containerID,
|
||||
Image: *container.Image,
|
||||
Status: status,
|
||||
Ports: convert.ToPorts(ipAddress, *container.Ports),
|
||||
}
|
||||
}
|
||||
|
||||
func getStatus(container containerinstance.Container) string {
|
||||
status := statusUnknown
|
||||
if container.InstanceView != nil && container.InstanceView.CurrentState != nil {
|
||||
status = *container.InstanceView.CurrentState.State
|
||||
}
|
||||
return status
|
||||
}
|
||||
|
||||
func (cs *aciContainerService) Run(ctx context.Context, r containers.ContainerConfig) error {
|
||||
if strings.Contains(r.ID, composeContainerSeparator) {
|
||||
return errors.New(fmt.Sprintf("invalid container name. ACI container name cannot include %q", composeContainerSeparator))
|
||||
|
|
@ -354,10 +335,7 @@ func (cs *aciContainerService) Delete(ctx context.Context, containerID string, r
|
|||
}
|
||||
|
||||
for _, container := range *cg.Containers {
|
||||
status := statusUnknown
|
||||
if container.InstanceView != nil && container.InstanceView.CurrentState != nil {
|
||||
status = *container.InstanceView.CurrentState.State
|
||||
}
|
||||
status := convert.GetStatus(container, cg)
|
||||
|
||||
if status == statusRunning {
|
||||
return errdefs.ErrForbidden
|
||||
|
|
@ -401,7 +379,7 @@ func (cs *aciContainerService) Inspect(ctx context.Context, containerID string)
|
|||
return containers.Container{}, errdefs.ErrNotFound
|
||||
}
|
||||
|
||||
return convert.ContainerGroupToContainer(containerID, cg, cc)
|
||||
return convert.ContainerGroupToContainer(containerID, cg, cc), nil
|
||||
}
|
||||
|
||||
type aciComposeService struct {
|
||||
|
|
|
|||
|
|
@ -386,7 +386,7 @@ func bytesToGb(b types.UnitBytes) float64 {
|
|||
}
|
||||
|
||||
// ContainerGroupToContainer composes a Container from an ACI container definition
|
||||
func ContainerGroupToContainer(containerID string, cg containerinstance.ContainerGroup, cc containerinstance.Container) (containers.Container, error) {
|
||||
func ContainerGroupToContainer(containerID string, cg containerinstance.ContainerGroup, cc containerinstance.Container) containers.Container {
|
||||
memLimits := 0.
|
||||
if cc.Resources != nil &&
|
||||
cc.Resources.Limits != nil &&
|
||||
|
|
@ -406,10 +406,7 @@ func ContainerGroupToContainer(containerID string, cg containerinstance.Containe
|
|||
command = strings.Join(*cc.Command, " ")
|
||||
}
|
||||
|
||||
status := "Unknown"
|
||||
if cc.InstanceView != nil && cc.InstanceView.CurrentState != nil {
|
||||
status = *cc.InstanceView.CurrentState.State
|
||||
}
|
||||
status := GetStatus(cc, cg)
|
||||
platform := string(cg.OsType)
|
||||
|
||||
c := containers.Container{
|
||||
|
|
@ -429,5 +426,17 @@ func ContainerGroupToContainer(containerID string, cg containerinstance.Containe
|
|||
RestartPolicyCondition: toContainerRestartPolicy(cg.RestartPolicy),
|
||||
}
|
||||
|
||||
return c, nil
|
||||
return c
|
||||
}
|
||||
|
||||
// GetStatus returns status for the specified container
|
||||
func GetStatus(container containerinstance.Container, group containerinstance.ContainerGroup) string {
|
||||
status := "Unknown"
|
||||
if group.InstanceView != nil && group.InstanceView.State != nil {
|
||||
status = "Node " + *group.InstanceView.State
|
||||
}
|
||||
if container.InstanceView != nil && container.InstanceView.CurrentState != nil {
|
||||
status = *container.InstanceView.CurrentState.State
|
||||
}
|
||||
return status
|
||||
}
|
||||
|
|
|
|||
|
|
@ -99,8 +99,7 @@ func TestContainerGroupToContainer(t *testing.T) {
|
|||
RestartPolicyCondition: "any",
|
||||
}
|
||||
|
||||
container, err := ContainerGroupToContainer("myContainerID", myContainerGroup, myContainer)
|
||||
assert.NilError(t, err)
|
||||
container := ContainerGroupToContainer("myContainerID", myContainerGroup, myContainer)
|
||||
assert.DeepEqual(t, container, expectedContainer)
|
||||
}
|
||||
|
||||
|
|
@ -408,3 +407,43 @@ func TestConvertToDockerRestartPolicyCondition(t *testing.T) {
|
|||
assert.Equal(t, toContainerRestartPolicy(containerinstance.OnFailure), "on-failure")
|
||||
assert.Equal(t, toContainerRestartPolicy(""), "any")
|
||||
}
|
||||
|
||||
func TestConvertContainerGroupStatus(t *testing.T) {
|
||||
assert.Equal(t, "Running", GetStatus(container(to.StringPtr("Running")), group(to.StringPtr("Started"))))
|
||||
assert.Equal(t, "Terminated", GetStatus(container(to.StringPtr("Terminated")), group(to.StringPtr("Stopped"))))
|
||||
assert.Equal(t, "Node Stopped", GetStatus(container(nil), group(to.StringPtr("Stopped"))))
|
||||
assert.Equal(t, "Node Started", GetStatus(container(nil), group(to.StringPtr("Started"))))
|
||||
|
||||
assert.Equal(t, "Running", GetStatus(container(to.StringPtr("Running")), group(nil)))
|
||||
assert.Equal(t, "Unknown", GetStatus(container(nil), group(nil)))
|
||||
}
|
||||
|
||||
func container(status *string) containerinstance.Container {
|
||||
var state *containerinstance.ContainerState = nil
|
||||
if status != nil {
|
||||
state = &containerinstance.ContainerState{
|
||||
State: status,
|
||||
}
|
||||
}
|
||||
return containerinstance.Container{
|
||||
ContainerProperties: &containerinstance.ContainerProperties{
|
||||
InstanceView: &containerinstance.ContainerPropertiesInstanceView{
|
||||
CurrentState: state,
|
||||
},
|
||||
},
|
||||
}
|
||||
}
|
||||
|
||||
func group(status *string) containerinstance.ContainerGroup {
|
||||
var view *containerinstance.ContainerGroupPropertiesInstanceView = nil
|
||||
if status != nil {
|
||||
view = &containerinstance.ContainerGroupPropertiesInstanceView{
|
||||
State: status,
|
||||
}
|
||||
}
|
||||
return containerinstance.ContainerGroup{
|
||||
ContainerGroupProperties: &containerinstance.ContainerGroupProperties{
|
||||
InstanceView: view,
|
||||
},
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -59,6 +59,9 @@ lint:
|
|||
check-license-headers:
|
||||
./scripts/validate/fileheader
|
||||
|
||||
check-go-mod:
|
||||
./scripts/validate/check-go-mod
|
||||
|
||||
FORCE:
|
||||
|
||||
.PHONY: all protos cli cross test lint
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ func (h contextCreateAWSHelper) saveCredentials(profile string, accessKeyID stri
|
|||
p := credentials.SharedCredentialsProvider{Profile: profile}
|
||||
_, err := p.Retrieve()
|
||||
if err == nil {
|
||||
return fmt.Errorf("credentials already exists")
|
||||
return fmt.Errorf("credentials already exist")
|
||||
}
|
||||
|
||||
if err.(awserr.Error).Code() == "SharedCredsLoad" && err.(awserr.Error).Message() == "failed to load shared credentials file" {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,32 @@
|
|||
#!/bin/sh
|
||||
|
||||
# Copyright The Compose Specification Authors.
|
||||
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
|
||||
set -uo pipefail
|
||||
mkdir -p /tmp/gomod
|
||||
cp go.* /tmp/gomod/
|
||||
go mod tidy
|
||||
DIFF=$(diff go.mod /tmp/gomod/go.mod && diff go.sum /tmp/gomod/go.sum)
|
||||
if [ "$DIFF" ]; then
|
||||
echo
|
||||
echo "go.mod and go.sum are not up to date"
|
||||
echo
|
||||
echo "$DIFF"
|
||||
echo
|
||||
exit 1
|
||||
else
|
||||
echo "go.mod is correct"
|
||||
fi;
|
||||
|
|
@ -394,7 +394,7 @@ func TestContainerRunAttached(t *testing.T) {
|
|||
t.Run("rm stopped container", func(t *testing.T) {
|
||||
res := c.RunDockerCmd("stop", container)
|
||||
res.Assert(t, icmd.Expected{Out: container})
|
||||
waitForStatus(t, c, container, "Terminated")
|
||||
waitForStatus(t, c, container, "Terminated", "Node Stopped")
|
||||
|
||||
res = c.RunDockerCmd("rm", container)
|
||||
res.Assert(t, icmd.Expected{Out: container})
|
||||
|
|
@ -664,15 +664,17 @@ func getContainerName(stdout string) string {
|
|||
return strings.TrimSpace(out[len(out)-1])
|
||||
}
|
||||
|
||||
func waitForStatus(t *testing.T, c *E2eCLI, containerID string, status string) {
|
||||
func waitForStatus(t *testing.T, c *E2eCLI, containerID string, statuses ...string) {
|
||||
checkStopped := func(logt poll.LogT) poll.Result {
|
||||
res := c.RunDockerCmd("inspect", containerID)
|
||||
containerInspect, err := ParseContainerInspect(res.Stdout())
|
||||
assert.NilError(t, err)
|
||||
if containerInspect.Status == status {
|
||||
return poll.Success()
|
||||
for _, status := range statuses {
|
||||
if containerInspect.Status == status {
|
||||
return poll.Success()
|
||||
}
|
||||
}
|
||||
return poll.Continue("Status %s != %s (expected) for container %s", containerInspect.Status, status, containerID)
|
||||
return poll.Continue("Status %s != %s (expected) for container %s", containerInspect.Status, statuses, containerID)
|
||||
}
|
||||
|
||||
poll.WaitOn(t, checkStopped, poll.WithDelay(5*time.Second), poll.WithTimeout(90*time.Second))
|
||||
|
|
|
|||
Loading…
Reference in New Issue