[EP] Remote Artifacts #419

otaviof · 2020-10-02T09:08:19Z

Enhancement proposal describing the concept of Remote Artifacts, and how this new concept will be expressed in Build operator. Related to #97.

HeavyWombat · 2020-10-05T14:14:13Z

I like the idea, especially for maybe large external assets you do not want or cannot have in a Git repository.

SaschaSchwarze0 · 2020-10-05T15:28:38Z

docs/proposals/remote-artifacts.md

+  artifacts:
+    - name: main-jar
+      url: https://nexus.company.com/app/main.jar
+      path: $(workspace)/classpath/main.jar


Should we maybe consider extending the source section instead ?

apiVersion: build.dev/v1alpha1 kind: Build metadata: name: nexus-jar spec: sources # A source of type=git must only exist once or be absent - type: git url: [email protected]:SCHWARZS/test-project.git revision: sascha-test credentials: name: ibm-github # A source of type=http can exist multiple times - type: http url: https://nexus.company.com/app/main.jar path: classpath/main.jar # Not sure if I would allow values that do not start with ${workspace} here but instead always have that as prefix # Credentials support for whatever we want, start with basic auth only, client-cert maybe in the future, we will need to determine it based on how the secret looks - type: http url: https://restricted.server.com/lib.jar credentials: name: restricted-server path: classpath/lib.jar # A source of type=http can have an optional extract flag set to true which means that path is interpreted as a directory instead of a file and the file content is extracted (TBD: can we autodetect the file type or do we need to make extract an enum or add another compressiontype parameter?) - type: http url: https://www.myserver.com/sources.zip extract: true path: sources

This would be an extensible mechanism. In the future we might support other types (loading from maybe some configmap where the cli placed the local sources).

we can introduce glue-code to autodetect the type based on the url, keeping the whole spec.source as simple as it is now.

I think that would be hard. An HTTPS URL can be a public Git repository (especially as we do not require the .git suffix at the moment), a SubVersion repository, a plain file and probably more.

I think given the distinction for types of data, one being VCS and the other remote artifacts, I think they should be described in different logical blocks. So, we also have a clear separation between those two concerts.

@otaviof a VCS resource is also remote. There is "just" a different protocol to download them.

This would be an extensible mechanism. In the future we might support other types (loading from maybe some configmap where the cli placed the local sources).

ConfigMap is certainly a valid use case, though with a cli upload I see PersistentVolume/PVC being a more likely result.

Another thing we should clarify is that "sources" are things that are intended to be present in the resulting image. There is a separate use case for "volume" support (like caches), in which case the data present in the volume is not included in the resulting container image.

... spec: sources # A source of type=git must only exist once or be absent - type: git url: [email protected]:SCHWARZS/test-project.git revision: sascha-test credentials: name: ibm-github

Wouldn't we want to employ the discriminator pattern?

spec: sources: - name: git type: Git git: url: ... ...

(note that type: Git may not be required, apimachinery can fill it in).

Same line of thought, I see a VCS as yet another remote artifact. I´m not able to understand the distinction.

Please consider latest commit, I'm adding a initial .spec.sources support with your inputs.

@otaviof thanks, I took a look.

http: settings for http, namely path (optional);

Is the new field from above required? we already have something call contextDir, can this serve the same purpose?

@adambkaplan @SaschaSchwarze0 @otaviof I have some concerns around spec.sources. First of all I think introducing a type is a nice way to distinguish the different assets(remote files, git,etc). I´m struggling to understand the value of moving from of a map(spec.source) into a list(spec.sources). My rational is:

This proposal does not explains the use cases on why a list is needed

This will break the current API

spec.source is for me one of the structs that is very simple to understand, and I would like to keep it this way. Adding support for a list of sources is going to add complexity on that API level.

supporting spec.sources will introduce some code complexity when generating the Taskrun. It would be good to highlight those and decide if it worth the effort.

@sbose78 probably we want your feedback also. Also, do we have some good references on how Build v1 did it(shouldnt bias us)?, but it will help to understand the rational there.

qu1queee · 2020-10-06T15:43:46Z

checking soon..(just in case someone was wondering)

qu1queee

Added some comments, I think I have doubts on:

concepts you define here. Mainly referring to "remote artifacts support", because we already do this( git repos)
Seems is not clear how to implement this, either via a new ClusterBuildStrategy or an extension of spec.source, I will prefer the second one.
The retrieval of the external artifact proposes a "wget" binary, I think we should propose a golang implementation of http get or reuse something from tekton
Is not clear how would an "artifact" be able to run. There should be a dependency call "base image for the artifact support", this is not mentioned here.

I love the idea, this is a great future, but still a lot of details to properly define.

docs/proposals/remote-artifacts.md

qu1queee · 2020-10-08T14:49:00Z

docs/proposals/remote-artifacts.md

+  artifacts:
+    - name: main-jar
+      url: https://nexus.company.com/app/main.jar
+      path: $(workspace)/classpath/main.jar


we can introduce glue-code to autodetect the type based on the url, keeping the whole spec.source as simple as it is now.

docs/proposals/remote-artifacts.md

qu1queee · 2020-10-08T15:05:21Z

docs/proposals/remote-artifacts.md

+happen before the build process starts. To achieve the objective, the operator will generate a new
+task step to download the artifacts.
+
+The download may happen using existing open-source software, more specifically `wget`. The


The "download" looks critical. We get this for free from tekton, Wouldn´t it make more sense to do this natively with "golang" or to see if Tekton have already something for us? e.g. they do not use a "git" binary for pulling, they have their own git pkg

I understand what Tekton does for the VCS (source-code), but what would it do for remote artifacts? Could we use Tekton to download them as well?

Ideally there would be a Tekton resource handling things like plain HTTP(S) download. But, I think there is not one.

It does not appear such a resource type exists. If we accept this proposal, I recommend submitting a TEP to see if we can get upstream Tekton buy-in.

I was mainly referring to do a native implementation in go, I would like to avoid introducing extra binaries dependencies in the code. We might not need Tekton at all.

I think we all agree this is not enforcing the usage of wget and that another more native implementation(e.g. tekton way) might be reused. Can we mention this somewhere?

Can we leverage the Tekton source to enable storage or something first?:
https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#resource-types

I think wget is a little weak. How about the private resource (with auth) or ftp?

PipelineResources at this time are most likely not going to get out of alpha stage. There has been a fair amount of consternation and churn around how exactly how to move forward, though.

But minimally I would not advise a PipelineResource styled path.

That said, if I had to pick, I'd say "custom tasks" might be the most likely path along the "tekton resource" angle. Also, submitting something "similar" but different most likely would get the response of "look at custom tasks".

See https://github.com/tektoncd/community/blob/master/teps/0002-custom-tasks.md for details.

there is also a "specializing task" which has some literature around it but no TEP as of yet

Yeah, a specific resource in upstream Tekton would be a hard sell at the moment given the direction PipelineResources is taking.

adambkaplan

In general, I like the idea of moving from one source to allowing multiple sources, where git and http (the remote artifact) are one of many types of sources.

However, in allowing this complexity we need to keep the simple cases simple. We can't require a significant amount of extra configuration for a user to create a simple build from source using kaniko, s2i, buildpacks, etc. Example - I would expect a build as follows to "just work":

apiVersion: build.dev/v1alpha1
kind: Build
metadata:
  name: simple
spec:
  sources:
    - name: src
      type: Git
      git:
        url: https://github.com/shipwright-io/build.git
...

docs/proposals/remote-artifacts.md

adambkaplan · 2020-10-13T19:18:04Z

docs/proposals/remote-artifacts.md

+  artifacts:
+    - name: main-jar
+      url: https://nexus.company.com/app/main.jar
+      path: $(workspace)/classpath/main.jar


This would be an extensible mechanism. In the future we might support other types (loading from maybe some configmap where the cli placed the local sources).

ConfigMap is certainly a valid use case, though with a cli upload I see PersistentVolume/PVC being a more likely result.

Another thing we should clarify is that "sources" are things that are intended to be present in the resulting image. There is a separate use case for "volume" support (like caches), in which case the data present in the volume is not included in the resulting container image.

docs/proposals/remote-artifacts.md

adambkaplan · 2020-10-13T19:26:19Z

docs/proposals/remote-artifacts.md

+happen before the build process starts. To achieve the objective, the operator will generate a new
+task step to download the artifacts.
+
+The download may happen using existing open-source software, more specifically `wget`. The


It does not appear such a resource type exists. If we accept this proposal, I recommend submitting a TEP to see if we can get upstream Tekton buy-in.

docs/proposals/remote-artifacts.md

qu1queee · 2020-10-19T10:21:39Z

@otaviof sorry for my late reply, I drop you some updates on my initial comments.

- rewording to clarity what remote artifact means; - using `sources` and expanding the input source concept; - updating all examples;

zhangtbj · 2020-10-26T05:09:00Z

In general, I like the idea of moving from one source to allowing multiple sources, where git and http (the remote artifact) are one of many types of sources.

However, in allowing this complexity we need to keep the simple cases simple. We can't require a significant amount of extra configuration for a user to create a simple build from source using kaniko, s2i, buildpacks, etc. Example - I would expect a build as follows to "just work":
apiVersion: build.dev/v1alpha1
kind: Build
metadata:
  name: simple
spec:
  sources:
    - name: src
      type: Git
      git:
        url: https://github.com/shipwright-io/build.git
...

I have two questions about the type of source.
Like this Git type, we already know it is a Git, do we still need:

      git:
        url: https://github.com/shipwright-io/build.git

to mention the git again? I think we can simplify to use url directly:

  sources:
    - name: src
      type: git
      url: https://github.com/shipwright-io/build.git

For http, I think it is similar:

  sources:
    - name: license-file
      type: http
      url: https://licenses.company.com/customer-id/license.tar
      http:
        path: $(workspace)/licenses/license.tar

It is already the http type, but still have another http for path, I think it is a little duplicate, it is better that show as:

  sources:
    - name: license-file
      type: http
      url: https://licenses.company.com/customer-id/license.tar
      path: $(workspace)/licenses/license.tar

coreydaley · 2020-10-29T00:27:03Z

docs/proposals/remote-artifacts.md

+The `source` section will be renamed to `sources` in order to accommodate more `type`s of inputs.
+Each entry will be composed of the following attributes:
+
+- `name`: source name (required);


I feel like name is superfluous here, what is the point of having it?

This is so we can use the merge patch strategy. Otherwise kubectl apply will default to overwriting everything in the sources array.

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#notes-on-the-strategic-merge-patch

coreydaley · 2020-10-29T00:28:52Z

docs/proposals/remote-artifacts.md

+- `sourceRef`: use a external resource, the name in this field is the resource name (optional);
+- `url`: the URL of the repository or remote artifact (optional);
+- `credentials`: the credentials to interact with the artifact (optional);
+- `http`: settings for `http`, namely `path` (optional);


What is path for here? Is this the local path that the file will be downloaded to? Why is it only available for the "http" type? Seems like path should be a top level element.

I've amended to explain .path is a inner attribute, please consider latest changes.

coreydaley · 2020-10-29T00:29:56Z

docs/proposals/remote-artifacts.md

+- `url`: the URL of the repository or remote artifact (optional);
+- `credentials`: the credentials to interact with the artifact (optional);
+- `http`: settings for `http`, namely `path` (optional);
+- `git`: settings for `git`, namely `revision` (optional);


Could we eliminate revision and just use standard git paths that reference a revision in the url?

I'm rewording this to mention it stays as original.

coreydaley · 2020-10-29T00:30:50Z

docs/proposals/remote-artifacts.md

+
+- `name`: source name (required);
+- `type`: input source type, `git` or `http` (required);
+- `sourceRef`: use a external resource, the name in this field is the resource name (optional);


Can you expand upon this fields usage?

I'm moving the field to the new "Alternatives" section at the end.

coreydaley · 2020-10-29T00:33:42Z

docs/proposals/remote-artifacts.md

+happen before the build process starts. To achieve the objective, the operator will generate a new
+task step to download the artifacts.
+
+The download may happen using existing open-source software, more specifically `wget`. The


I would prefer to see us use pure golang for the downloading instead of an external tool such as wget, i don't like having to rely on os provided tools.

I like idea from Corey. We will eventually face a Build which has a longer list of sources. For all these sources beside the git source (which we will probably want to continue to handle using Tekton's Git resource), I envision one Task step implemented by ourselves using Golang. Within our code we can then do optimizations like parallel downloads for different sources and also can handle and report errors in a better way than by invoking an external command.

I also like the idea of creating or own tool for that purpose. However, I see wget as a simple starting point, on which we could potentially develop our own tool in parallel.

So, how about get started with wget and evaluate the new tooling on its own track?

I raised the same concern on some comments ago, I do not see why we need to rely on a binary. #419 (comment)

I think we can agree that we can implement the downloader, regardless of whether we build our own in go vs. "buy" it (by using a fixed container image with wget). IMO deciding which approach to take is beyond what is necessary to mark this EP as "implementable".

sbose78 · 2020-10-29T03:13:19Z

In order to avoid completely breaking existing API usage with spec.source, do we want to support both spec.source and spec.sources for a couple of minor releases where the controller would look for spec.source and populate spec.sources. Eventually, we drop the git-specific spec.source altogether ?

sbose78 · 2020-10-29T03:15:59Z

docs/proposals/remote-artifacts.md

+container image which contains this software will be specified via environment variable, and when
+not informed will use a default value.
+
+Therefore, the operator needs to generate `wget` commands with arguments in order to download the


the operator needs to generate wget commands with arguments in order to download the

The buildrun controller needs to generate a TaskRun step that would generate the wget command to download the artifacts specified

Thanks, that's a good addition. Please consider latest commit 01ace39.

sbose78 · 2020-10-29T03:17:07Z

docs/proposals/remote-artifacts.md

+  sources:
+    - name: project-logo
+      type: http
+      url: https://user-images.githubusercontent.com/2587818/92114986-69bfb600-edfa-11ea-820e-96cdb1014f58.png


Could you use a more realistic example like a jar artifact in all examples, please?

Same as in here.

sbose78 · 2020-10-29T03:17:34Z

docs/proposals/remote-artifacts.md

+spec:
+  sources:
+    - type: http
+      url: https://licenses.company.com/customer-id/license.tar


Could you use a more realistic example like a jar artifact in all examples, please?

Same as in here.

sbose78 · 2020-10-29T03:17:41Z

docs/proposals/remote-artifacts.md

+  sources:
+    - name: license-file
+      type: http
+      url: https://licenses.company.com/customer-id/license.tar


Could you use a more realistic example like a jar artifact in all examples, please?

The initial text was using a Jar file, but it wind up in questions about the dependency management itself. So, moved that to a simpler thing, a license file.

Please note a more Java like example is kept here.

coreydaley · 2020-10-29T04:17:56Z

docs/proposals/remote-artifacts.md

+metadata:
+  name: license-file
+spec:
+  sources:


I am wondering if sources really makes sense here. I think of source as a git repository or something to that affect. Maybe this should be something more along the lines of dependencies like you would list in a maven file?

My vote is for inputs which would be a symmetric naming together with the output image that we already have in the Build.

@SaschaSchwarze0 are you okay with sources and the path ahead to unify them later on?

@SaschaSchwarze0 are you okay with sources and the path ahead to unify them later on?

I am okay with sources, yes. (But I doubt we would ever change this in the future. ;-) )

I´m concerned more than one person is not fully buying the spec.sources , what are the implications for this EP to move into spec.inputs rather than spec.sources, it will also keep the API clean for now. And in another EP we will deal with multiple gits, where we can tackle that modifications to spec.source.

I'm okay to use .spec.inputs for this purpose. Do we have objections on .spec.inputs?

not from my side :)

@sbose78, @adambkaplan, @gabemontero, @coreydaley would you object to use .spect.inputs instead?

coreydaley · 2020-10-29T04:20:56Z

I like the idea, especially for maybe large external assets you do not want or cannot have in a Git repository.

If additional large files is the case, wouldn't we support whatever system their source code uses to manage dependencies such as maven, bundler, go mod, etc?

As far as other types of large assets go, I think that they would be using something like a third party object store such as S3 for images, videos, and other binary downloads.

qu1queee · 2020-11-09T10:34:14Z

@otaviof does this requires to mention the support for both spec.source and spec.sources for a couple of minor releases? From my side I can merge this after that is documented, but I also see @sbose78 drop some request for changes, pls take a look.

otaviof · 2020-11-09T11:20:10Z

@otaviof does this requires to mention the support for both spec.source and spec.sources for a couple of minor releases? From my side I can merge this after that is documented, but I also see @sbose78 drop some request for changes, pls take a look.

I'm pushing changes mentioning .spec.source and .spec.sources side-by-side. And, I would like to bring this EP on today's community meeting, I would like to bring multiple Git repositories back to discussion. Thanks.

- keeping `source` in place, and addding `source` with new remote artifacts; - avoiding dealing with multiple Git repositories on this EP; - updating list of reviewers;

docs/proposals/remote-artifacts.md

SaschaSchwarze0 · 2020-11-10T07:43:05Z

docs/proposals/remote-artifacts.md

+```yml
+---
+apiVersion: build.dev/v1alpha1
+kind: BuildSource
+metadata:
+  name: license-file
+spec:
+  sources:
+    - name: license.tar
+      type: http
+      url: https://licenses.company.com/customer-id/license.tar
+      http:
+        path: $(workspace)/licenses/license.tar
+```


A question around the BuildSource. Within the Build's spec.sources, it is used to from one source entry to reference an external definition. Based on that, may expectation would be that the external build source would only contain a single spec like this:

--- apiVersion: build.dev/v1alpha1 kind: BuildSource metadata: name: license-file spec: type: http url: https://licenses.company.com/customer-id/license.tar http: path: $(workspace)/licenses/license.tar

Should we have multiple entries with their own name in the BuildSource, then we'll have to define how this is merged with the other entries in the Build's sources.

I think here we may benefit from a slice of entries. Given that we may be downloading a number of dependencies from a single external source, and we can bundle together in this slice fashion. It also keeps aligned with Build resource where it will be available as a array/slice as well.

shipwright-io#419 (comment) Co-authored-by: Adam Kaplan <[email protected]>

adambkaplan · 2020-11-10T19:37:38Z

Volumes feature has been captured in #478.

adambkaplan

@otaviof a few requested changes from my latest pass at the draft.

We've had a lot of lengthy conversations on this EP. I'd like us to turn to the core decision - whether or not we agree the design as laid out in this proposal is implementable.

adambkaplan · 2020-11-11T18:57:22Z

docs/proposals/remote-artifacts.md

+The `source` section will be renamed to `sources` in order to accommodate more `type`s of inputs.
+Each entry will be composed of the following attributes:
+
+- `name`: source name (required);


This is so we can use the merge patch strategy. Otherwise kubectl apply will default to overwriting everything in the sources array.

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#notes-on-the-strategic-merge-patch

adambkaplan · 2020-11-11T19:06:32Z

docs/proposals/remote-artifacts.md

+
+We will address supporting multipe Git repositories in a future enhancement proposal. This will involve re-defining `/workspace/source` location and the `$workspace` placeholder.
+
+### Standalone CRD


This should be placed in an "Alternatives" section at the bottom of the proposal. I believe we decided that we are not going to pursue this approach.

Leaving this in the main body confuses what is in the proposal vs. out. See the proposal template for guidance:

https://github.com/shipwright-io/build/blob/master/docs/proposals/guidelines/proposal-template.md

Following the template, the standalone CRD alternative design was moved into a section at the end.

adambkaplan · 2020-11-11T19:09:31Z

docs/proposals/remote-artifacts.md

+happen before the build process starts. To achieve the objective, the operator will generate a new
+task step to download the artifacts.
+
+The download may happen using existing open-source software, more specifically `wget`. The


I think we can agree that we can implement the downloader, regardless of whether we build our own in go vs. "buy" it (by using a fixed container image with wget). IMO deciding which approach to take is beyond what is necessary to mark this EP as "implementable".

docs/proposals/remote-artifacts.md

adambkaplan · 2020-11-11T19:12:26Z

docs/proposals/remote-artifacts.md

+```yml
+---
+apiVersion: build.dev/v1alpha1
+kind: BuildSource


This references the original CRD style of declaring a downloaded resource, which IIRC we are not pursuing. Please update.

Moved to the new "Alternatives" section, please consider.

- Moving `sourceRef` to alternatives section; - Adding "Alternatives" section, and moving standalong CRD into; - Minor changes and formatting;

qu1queee · 2020-11-13T14:20:58Z

docs/proposals/remote-artifacts.md

+
+Then, we can create the `Build` resource, as per:
+
+```yml


@otaviof pls correct me if I´m wrong, but here the example is based on the assumption that we support a new BuildSource CRD. If we do not have the BuildSource CRD in place, then we will still need to have

A Build instance to define the git source code

Two BuildRuns, each one overriding the spec.sources for each logo type

is the above correct?

Yes, correct @qu1queee. The example was made to illustrate both scenarios at once, but it might have been too much leaning towards the "Alternative" scenario.

qu1queee · 2020-11-16T15:38:39Z

/lgtm

openshift-ci-robot · 2020-11-16T15:38:45Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qu1queee

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [qu1queee]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

qu1queee

I have no further comments on this EP; therefore approving, thanks @otaviof for addressing each of my questions

Remote Artifacts EP.

55e8181

openshift-ci-robot requested review from gabemontero and qu1queee October 2, 2020 09:08

otaviof added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 2, 2020

otaviof mentioned this pull request Oct 5, 2020

October 5th, 2020 Community Meeting #418

Closed

SaschaSchwarze0 reviewed Oct 5, 2020

View reviewed changes

qu1queee requested changes Oct 8, 2020

View reviewed changes

qu1queee mentioned this pull request Oct 12, 2020

October 12th, 2020 Community Meeting #436

Closed

adambkaplan reviewed Oct 13, 2020

View reviewed changes

qu1queee mentioned this pull request Oct 19, 2020

October 19th, 2020 Community Meeting #444

Closed

This was referenced Oct 22, 2020

inject source via config map / secrets feature #48

Open

inject source via image feature #49

Open

Remote Artifacts EP

5c2dcee

- rewording to clarity what remote artifact means; - using `sources` and expanding the input source concept; - updating all examples;

otaviof mentioned this pull request Oct 23, 2020

October 26th Community Meeting #446

Closed

coreydaley reviewed Oct 29, 2020

View reviewed changes

sbose78 reviewed Oct 29, 2020

View reviewed changes

coreydaley reviewed Oct 29, 2020

View reviewed changes

otaviof mentioned this pull request Oct 31, 2020

November 2nd Community Meeting #457

Closed

otaviof mentioned this pull request Nov 9, 2020

November 9th Community Meeting #469

Closed

Remote Artifacts EP:

a112672

- keeping `source` in place, and addding `source` with new remote artifacts; - avoiding dealing with multiple Git repositories on this EP; - updating list of reviewers;

otaviof force-pushed the ep-remote-artifacts branch from 2d1c2ae to a112672 Compare November 9, 2020 11:26

adambkaplan reviewed Nov 9, 2020

View reviewed changes

docs/proposals/remote-artifacts.md Outdated Show resolved Hide resolved

docs/proposals/remote-artifacts.md Outdated Show resolved Hide resolved

SaschaSchwarze0 reviewed Nov 10, 2020

View reviewed changes

otaviof and others added 3 commits November 10, 2020 11:27

Adam's suggestion

6f95ad8

shipwright-io#419 (comment) Co-authored-by: Adam Kaplan <[email protected]>

Updating examples to have both source and sources.

02020e8

Being more accurate on controller terminology.

01ace39

adambkaplan reviewed Nov 11, 2020

View reviewed changes

Remote Artifacts EP

a34984a

- Moving `sourceRef` to alternatives section; - Adding "Alternatives" section, and moving standalong CRD into; - Minor changes and formatting;

qu1queee reviewed Nov 13, 2020

View reviewed changes

qu1queee self-requested a review November 16, 2020 15:30

openshift-ci-robot assigned qu1queee Nov 16, 2020

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 16, 2020

openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 16, 2020

qu1queee approved these changes Nov 16, 2020

View reviewed changes

openshift-merge-robot merged commit ee2a4b4 into shipwright-io:master Nov 16, 2020

otaviof deleted the ep-remote-artifacts branch November 17, 2020 06:12

otaviof mentioned this pull request Feb 23, 2021

Remote Artifacts #615

Closed


		We will address supporting multipe Git repositories in a future enhancement proposal. This will involve re-defining `/workspace/source` location and the `$workspace` placeholder.

		### Standalone CRD

[EP] Remote Artifacts #419

[EP] Remote Artifacts #419

Conversation

otaviof commented Oct 2, 2020 • edited Loading

HeavyWombat commented Oct 5, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof Oct 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qu1queee commented Oct 6, 2020

qu1queee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhangtbj Oct 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gabemontero Oct 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adambkaplan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qu1queee commented Oct 19, 2020

zhangtbj commented Oct 26, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof Nov 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otaviof Nov 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbose78 commented Oct 29, 2020

Choose a reason for hiding this comment

otaviof Nov 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coreydaley commented Oct 29, 2020

qu1queee commented Nov 9, 2020

otaviof commented Nov 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adambkaplan commented Nov 10, 2020

adambkaplan left a comment

Choose a reason for hiding this comment

otaviof commented Oct 2, 2020 •

edited

Loading

otaviof Oct 23, 2020 •

edited

Loading

zhangtbj Oct 26, 2020 •

edited

Loading

gabemontero Oct 26, 2020 •

edited

Loading

otaviof Nov 12, 2020 •

edited

Loading

otaviof Nov 10, 2020 •

edited

Loading

otaviof Nov 10, 2020 •

edited

Loading