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

[Feature] Pull archived source from remote location #30

Closed
allxiao opened this issue Jul 17, 2019 · 1 comment · Fixed by #64
Closed

[Feature] Pull archived source from remote location #30

allxiao opened this issue Jul 17, 2019 · 1 comment · Fixed by #64

Comments

@allxiao
Copy link

allxiao commented Jul 17, 2019

In the current SCS flow, the user uploads a executable fat-JAR to Azure Blob storage.

To combine it with the PBS flow we want PBS to generate an image from that JAR. This requires PBS to download the JAR from a given URL (blob endpoint with SAS token in the query parameter), and use the JAR as the user source to build the image.

@mgibson1121
Copy link

mgibson1121 commented Jul 25, 2019

As a user of build-service system
I want to reference source code that lives in a blobstore when creating an image type
So that build service system can execute builds against it

Given I have a file stored in a blobstore that contains source code in at https://locationofblob.tar.tgz
And I configure my image type to look like this

apiVersion: build.pivotal.io/v1alpha1
kind: Image
metadata:
  name: sample-image
spec:
  serviceAccount: service-account 
  builderRef: sample-builder
  image: gcr.io/project-name/app
  cacheSize: "1.5Gi"
  failedBuildHistoryLimit: 5
  successBuildHistoryLimit: 5
  source:
    blob:
      url: https://locationofblob.jar

When I run kubectl image apply and reference this image type
Then build service system will execute builds against the source code @ https://locationofblob.jar

Notes

  • Build service system should always try to extract whatever artifact is passed through the blob url
    • If we can't extract the blow, it should fail
  • We will play add on story to add a type parameter to the blob field separately
    • We'd be interested in feedback from @scothis and @ArieShout for what types should be supported
  • Validation out of scope of this story
  • Monitoring not required in the scope of the story

djoyahoy pushed a commit that referenced this issue Aug 1, 2019
- Refactor the git package to move all structs to private
- Update the git package testing to enable us to tests some private
  behavior
- Changed the builder to start using cloudfoundry/cnb:bionic
- Use cloudfoundry/build:base-cnb as the run-image because source-init image required git
  and the cloudfoundry/run:bionic

Closes #30

Signed-off-by: Danny Joyce <djoyce@pivotal.io>
djoyahoy pushed a commit that referenced this issue Aug 1, 2019
- Refactor the git package to move all structs to private
- Update the git package testing to enable us to tests some private
  behavior
- Changed the builder to start using cloudfoundry/cnb:bionic
- Use cloudfoundry/build:base-cnb as the run-image because source-init image required git
  and the cloudfoundry/run:bionic

Closes #30

Signed-off-by: Danny Joyce <djoyce@pivotal.io>
joaopapereira added a commit that referenced this issue Aug 2, 2019
- Refactor the git package to move all structs to private
- Update the git package testing to enable us to tests some private
  behavior
- Changed the builder to start using cloudfoundry/cnb:bionic
- Use cloudfoundry/build:base-cnb as the run-image because source-init image required git
  and the cloudfoundry/run:bionic

Closes #30

Signed-off-by: Danny Joyce <djoyce@pivotal.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants