Merge remote-tracking branch 'origin/main' into ecs-import

Signed-off-by: Nicolas De Loof <[email protected]>

.github/ISSUE_TEMPLATE.md

@@ -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.):**

.github/workflows/ci.yml

@@ -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

CONTRIBUTING.md

@@ -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
+[[email protected]](mailto:[email protected]).
+
+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 <[email protected]>
+
+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.

Dockerfile

@@ -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

MAINTAINERS

@@ -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 = "[email protected]"
+	GitHub = "rumpl"
+
+	[people.gtardif]
+	Name = "Guillaume Tardif"
+	Email = "[email protected]"
+	GitHub = "gtardif"
+
+	[people.chris-crone]
+	Name = "Christopher Crone"
+	Email = "[email protected]"
+	GitHub = "chris-crone"
+

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

aci/backend.go

@@ -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 {

aci/convert/convert.go

@@ -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
 }

aci/convert/convert_test.go

@@ -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,
+		},
+	}
+}

builder.Makefile

@@ -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

ecs/context.go

@@ -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" {

scripts/validate/check-go-mod

@@ -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;

tests/aci-e2e/e2e-aci_test.go

@@ -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))