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

Publish source code to artifact like Jfrog #1776

Open
RATANAJANGIR opened this issue May 23, 2023 · 8 comments
Open

Publish source code to artifact like Jfrog #1776

RATANAJANGIR opened this issue May 23, 2023 · 8 comments
Labels
status/blocked Issue or PR that is blocked. See comments. type/enhancement Issue that requests a new feature or improvement.

Comments

@RATANAJANGIR
Copy link

Is there any feature in existing CNB lifecycle command to just build source code and publish package to artifact like Jfrog artifact..

or user can choose option, want to build image or not.

if don't then just publish package to artifact like wheel, JAR package etc.

@RATANAJANGIR RATANAJANGIR added status/triage Issue or PR that requires contributor attention. type/enhancement Issue that requests a new feature or improvement. labels May 23, 2023
@AidanDelaney
Copy link
Member

@RATANAJANGIR We don't currently have exporters for artifacts other than OCI images. If you wanted to contribute a more generic artifact exporter, then it would be great to catch up with us in our weekly meeting on Thursday (https://buildpacks.io/community/) and start a document?

@RATANAJANGIR
Copy link
Author

@AidanDelaney Sure, I can create one lifecycle to export only package artifact after running build lifecycle.
But I have one question, do we need change in Pack CLI as well ?

@loewenstein
Copy link

I would think such a document / RFC would have to start way before worrying about whether pack needs a code change.

Currently, the buildpacks spec has no notion about any artefact other than images and maybe image layers (if it makes sense to consider them separately).

There's buildpacks that call mvn or similar and hence produce e.g. JAR artefacts, but as far as a contract between platform and buildpack that's all arbitrary content of image layers.

I think there's buildpacks/rfcs#274 that could be interesting in that direction. I wouldn't think that's going to be a rapid change though.

What is the use case of using Cloud Native Buildpacks for the kind of artefacts you are interested in? A lot of existing CI/CD infrastructure and toiling is probably well established and easily available to reach that goal instead I imagine.

@natalieparellano
Copy link
Member

@jjbustamante
Copy link
Member

jjbustamante commented Jun 7, 2023

Hi @RATANAJANGIR

I am curious about this use case, but, in the case of jar artifacts for example, can't you use Maven or Gradle plugins to publish your artifacts to Jfrog? You can take a look at the Paketo Buildpacks and be able to get that behavior.

The RFC mentioned by @natalieparellano and @loewenstein could be something helpful but it defines lifecycle can push other types of OCI artifacts into the registry. You mentioned: publish package to artifact like wheel, JAR package etc. so I understand you want to push another kind of artifacts that are not OCI images. Unless you want to push a JAR or several JARs into an OCI image and identify that image with some media-type.

A made-up example from the RFC

[[artifact]]
tag = "jar"
file = "my-app.jar"    

[[artifact.labels]]
ConfigMediaType       = "application/vnd.jar.config.v1+json"
ContentLayerMediaType = "application/vnd.jarcontent.layer.v1+jar"

@jjbustamante jjbustamante added status/discussion-needed Issue or PR that requires in-depth discussion. and removed status/triage Issue or PR that requires contributor attention. labels Aug 15, 2023
@jjbustamante
Copy link
Member

I am gonna mark this one as block because we need to implement this RFC first, then we can talk about if this feature makes sense on pack or it could be something the lifecycle can do or it could be done using a buildpack for it.

@jjbustamante jjbustamante added the status/blocked Issue or PR that is blocked. See comments. label Aug 17, 2023
@jjbustamante
Copy link
Member

Block on RFC-0113

@jjbustamante jjbustamante removed the status/discussion-needed Issue or PR that requires in-depth discussion. label Aug 17, 2023
@jjbustamante
Copy link
Member

I think this issue is still block, but I am curious if we ever create a ticket for RFC-0113? I don't think so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/blocked Issue or PR that is blocked. See comments. type/enhancement Issue that requests a new feature or improvement.
Projects
None yet
Development

No branches or pull requests

5 participants