Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add design proposal for supporting dependencies between build artifacts #4794

Merged

Conversation

gsquared94
Copy link
Collaborator

Added a design proposal for supporting build artifact dependencies.

@codecov
Copy link

codecov bot commented Sep 16, 2020

Codecov Report

Merging #4794 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #4794   +/-   ##
=======================================
  Coverage   71.73%   71.73%           
=======================================
  Files         353      353           
  Lines       12090    12090           
=======================================
  Hits         8673     8673           
  Misses       2773     2773           
  Partials      644      644           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 65583f1...f7df32b. Read the comment docs.

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
Copy link
Member

@tejal29 tejal29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation. Few other follows up can be discussed in a team meeting setting.

just 1 qq. (pardon me if this was clarified in the design document linked)

build:
  tagPolicy:
    gitCommit: {}
  - image:simple-go-app
    ..
   - image: leeroy-app
     requires:
       - image: simple-go-app
         alias: BASE

In this case with the tagging strategy, for the dependent docker build arg BASE will replaced with fully qualified image name right.
e.g. if default-repo is set to "gcr.io/X`

BASE = "gcr.io/X/simple-go-app@<TAG>

Maybe you could add this in section called "Docker Builder Changes" if not in the parent design document.

@gsquared94
Copy link
Collaborator Author

Thanks for the explanation. Few other follows up can be discussed in a team meeting setting.

just 1 qq. (pardon me if this was clarified in the design document linked)

build:
  tagPolicy:
    gitCommit: {}
  - image:simple-go-app
    ..
   - image: leeroy-app
     requires:
       - image: simple-go-app
         alias: BASE

In this case with the tagging strategy, for the dependent docker build arg BASE will replaced with fully qualified image name right.
e.g. if default-repo is set to "gcr.io/X`

BASE = "gcr.io/X/simple-go-app@<TAG>

Maybe you could add this in section called "Docker Builder Changes" if not in the parent design document.

Added section Referencing dependencies inside docker builder and also added future work with initial idea about how the other builder could support it.

Copy link
Member

@briandealwis briandealwis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should have submitted this as individual comments rather than as a review

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
@gsquared94 gsquared94 changed the title Add design proposal for build artifact dependencies. Add design proposal for supporting dependencies between build artifacts Sep 21, 2020
Copy link
Contributor

@nkubala nkubala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks really good, I think it's close to done. @briandealwis and @tejal29 any final feedback?


There are two quirks in this:
- It reports in the order of artifacts in the `Artifact` slice instead of the actual order in which they get built.
- It only reports a single artifact build failure even though there could have been multiple failures.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#2077 and #2000 :)

Copy link
Member

@tejal29 tejal29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGMT to me except for Buildpacks. I will defer to Brain.

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved

Skaffold currently allows specifying the `concurrency` property in `build` which affects how many builds can be running at the same time. However it doesn't address the issue of certain builders (`jib` and `bazel`) not being safe for multiple concurrent runs against the same workspace or context. We can fix this also since we are reworking the build controller anyways.

We define a concept of lease on workspaces by preprocessing the list of artifacts. Each builder tries to acquire a lease on the context/workspace prior to starting the build. Only workspaces associated with concurrency-safe builders allot multiple leases, otherwise it assigns one lease at a time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if we have several artifacts of different builder-type but same context?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only workspaces associated with concurrency-safe builders allot multiple leases

So even if one builder is concurrency unsafe, it'll be single leases for that context.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we need a builder interface (rather than just the ArtifactBuilder function signature). Can you sketch out what this interface would look like?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

- Unique artifact aliases.
- We ensure that within *each* artifact dependency slice the aliases are unique.
- Valid aliases
- Since aliases are used as environment variable keys or template keys we validate that they match the regex `[a-zA-Z_][a-zA-Z0-9_]*`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should move this requirement into the applicable builders. Just in case some builders may find it useful to be able to alias image-refs directly, like a rewrite rule.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think adding it as a config validation helps to show the error early and immediately. I've changed it to validate only for docker and custom builders where we are using the alias with naming restrictions.

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
}
```

This necessitates all multi-artifact builder implementations to also accept a slice of already built artifacts' information. All single artifact builders require an `ArtifactResolver` that can provide the required artifacts.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be helpful to explain why multi-artifact builders need a list of already-built artifacts (vs an ArtifactResolver)

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved

Skaffold currently allows specifying the `concurrency` property in `build` which affects how many builds can be running at the same time. However it doesn't address the issue of certain builders (`jib` and `bazel`) not being safe for multiple concurrent runs against the same workspace or context. We can fix this also since we are reworking the build controller anyways.

We define a concept of lease on workspaces by preprocessing the list of artifacts. Each builder tries to acquire a lease on the context/workspace prior to starting the build. Only workspaces associated with concurrency-safe builders allot multiple leases, otherwise it assigns one lease at a time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we need a builder interface (rather than just the ArtifactBuilder function signature). Can you sketch out what this interface would look like?

Copy link
Member

@briandealwis briandealwis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
docs/design_proposals/artifact-dependencies.md Outdated Show resolved Hide resolved
@gsquared94 gsquared94 merged commit 558dfa0 into GoogleContainerTools:master Sep 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants