search

facebook / buck2

Build system, successor to Buck
https://buck2.build/
Apache License 2.0
3.35k stars 195 forks source link

Integrate with dotslash #565

Closed bigfootjon closed 3 months ago

bigfootjon commented 3 months ago

As discussed internally, we want to use dotslash as a distribution mechanism for bucks. This PR stands up the initial integration.

In order to test I had to fix some things in the GitHub Actions workflows, so I included those here.

Ref: https://dotslash-cli.com/ Ref: https://github.com/facebook/dotslash-publish-release

Tasks: T175738402

Test plan:

See this action on my fork: https://github.com/bigfootjon/buck2/actions/runs/7836463888/job/21385144587

Which created this release: https://github.com/bigfootjon/buck2/releases/tag/2024-02-08

It contains a correct dotslash file: https://gist.github.com/bigfootjon/39c63a3a6772f66fc13c84c9116a56d7

(this version predates a fix I made to use "buck2" as the filename instead of hermes, oops)

When run using the opensource version of dotslash it correctly downloads and runs the right binary!

bolinfest commented 3 months ago

I'm very excited to see this!

Since you may be the first "real" user of this action, I'm certainly interested in feedback on the API.

One thing I didn't have a chance to build in is the ability to add metadata to the generated DotSlash file along the lines of the code-compose-lsp example in the blog post:

https://engineering.fb.com/2024/02/06/developer-tools/dotslash-simplified-executable-deployment/

This buck2 use case might be a good case to explore this space!

bolinfest commented 3 months ago

@bigfootjon I'm still seeing hermes in this PR?

bigfootjon commented 3 months ago

I'm very excited to see this!

Since you may be the first "real" user of this action, I'm certainly interested in feedback on the API.

So far it looks great! It was super easy to setup, I did have some slight confusion over what to set as the "path" for a single file archive, but the dotslash-cli.com docs covered this case so I wasn't blocked.

One thing I didn't have a chance to build in is the ability to add metadata to the generated DotSlash file along the lines of the code-compose-lsp example in the blog post:

https://engineering.fb.com/2024/02/06/developer-tools/dotslash-simplified-executable-deployment/

This buck2 use case might be a good case to explore this space!

Yeah metadata like that could be useful, especially provenance info. For a V1 this seems to work perfectly fine. Are you going to open a GitHub Issue in the action repo about this feature?

facebook-github-bot commented 3 months ago

@bigfootjon has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

bolinfest commented 3 months ago

Yeah metadata like that could be useful, especially provenance info. For a V1 this seems to work perfectly fine. Are you going to open a GitHub Issue in the action repo about this feature?

If you were willing to open one with a concrete use case (rather than a theoretical one that I make up), I think that would be a more compelling starting point, if that's OK.

facebook-github-bot commented 3 months ago

@bigfootjon has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

bigfootjon commented 3 months ago

If you were willing to open one with a concrete use case (rather than a theoretical one that I make up), I think that would be a more compelling starting point, if that's OK.

https://github.com/facebook/dotslash-publish-release/issues/2

bolinfest commented 3 months ago

Also, the name in the DotSlash file is buck2, right? I wonder if we should embed the version in the name or perhaps formally make that a separate field in the JSON.

An advantage of a separate field is that it might be helpful with DotSlash garbage collection later if we could identify "you have N different versions of the same DotSlash file"...

/cc @zertosh @dtolnay

bigfootjon commented 3 months ago

I think adding a standard header to the generated file would serve this purpose, especially if it included the tag/release it came from (what I proposed in the above issue)

bolinfest commented 3 months ago

Yes, but I also want to have “best practices” for people who generate their own DotSlash files through other means so we can exploit this consistency for things like garbage collection.

On Fri, Feb 9, 2024 at 8:52 AM Jon Janzen @.***> wrote:

I think adding a standard header to the generated file would serve this purpose, especially if it included the tag/release it came from (what I proposed in the above issue)

— Reply to this email directly, view it on GitHub https://github.com/facebook/buck2/pull/565#issuecomment-1936262312, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFAD7KIYHC3IVT22XCJX6TYSZH3BAVCNFSM6AAAAABDAKTS2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWGI3DEMZRGI . You are receiving this because you commented.Message ID: @.***>