Initial File System - Bounty-to-Hire

jdegoes commented 1 week ago

This is the official ticket for Golem Cloud's Bounty-to-Hire event!

This is your chance to contribute to open source, potentially win a $15,000 bounty, and maybe even land a new 100% Rust job building Golem, a next-generation open source platform for building and deploying bulletproof backends.

The specification for this ticket is attached as a PDF:

Initial File System Spec v3.pdf

Important Websites

Discord: On the official Discord for the Golem open source project, you may chat with fellow participants and learn more about Golem, but remember, the Golem engineering team will not assist you in any way with building the project or becoming familiar with the code base.
Github: On the Github repository for the Golem open source project, you can fork the repo, browse the source code, and find links to other resources, such as the Golem Cloud website.

Timeline

October 11: Coding begins. You can see the requirements and begin working on the ticket.
October 28: Judging begins. You may open pull requests that satisfy the requirements. We may pick a winner anytime after October 28, but not before. So even if you finish early, you should not submit your solution until October 28th. We do not guarantee to pick a winner on October 28th, and may require that contributors revise their pull requests in order to qualify.
November 4th. The winner is officially announced.
November 11th. Interviews with all willing and qualified participants will be complete and one or more job offers will be sent out.

The Structure

One Winner. Whether there is a single complete solution or five, only one will be awarded the $15,000 bounty. In the unlikely event that no solutions satisfy the requirements, no bounty will be awarded, no pull requests will be merged, and no job offers extended.
Guaranteed Interview. If you submit an original solution that is reasonably complete, you are guaranteed an interview for our open position. If we end up with 5 solutions, then each of those five participants will be given an interview for the opening.
Job Offer. We intend to hire at least one developer from the pool of original and complete solutions. Our preference is to hire the winner, but this depends on many factors, and in some cases (e.g. the winner is not looking for a job), we might extend job offers to others.

The Rules

No Assistance. We won't help you in any way. If you need clarification on the specification only, then ask on THIS Github issue. Do not ask in the Discord. You are free to ask questions to fellow participants on the Discord, or to ask general questions about Golem, not related to the source code or contributing to the project.
No Cheating. Absolutely no copying or deriving solutions from other developers. Though you should feel free to use Copilot-like solutions when you develop, if you use AI to generate a full solution (which definitely won't work and probably won't even compile), you will be banned from participation in the repository.
Have Fun. Bounties can get competitive but remember to enjoy the process. There will be more employment and bounty opportunities ahead for anyone who ends up submitting a meaningful pull request.

Note on Plagiarism

We recommend developing in private, so no other developers can copy or derive from your work. Before opening a pull request on October 28, we recommend first sending a ZIP archive of your complete solution to john@ziverge.com, to verify original authorship of the source code in the event of contested authorship.

Good luck to everyone!

jdegoes commented 1 week ago

/bounty $15000

algora-pbc[bot] commented 1 week ago

💎 $15,000 bounty • Golem Cloud

Steps to solve:

Start working: Comment /attempt #1004 with your implementation plan
Submit work: Create a pull request including /claim #1004 in the PR body to claim the bounty
Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to golemcloud/golem!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @volfcan	Oct 12, 2024, 10:24:46 AM	WIP
🟢 @kumarvivek1752	Oct 13, 2024, 4:24:34 PM	WIP
🟢 @kvpan	Oct 13, 2024, 5:14:25 PM	WIP
🟢 @nickconway	Oct 13, 2024, 7:43:09 PM	WIP
🟢 @cmwelsh	Oct 13, 2024, 10:01:37 PM	WIP
🟢 @uurl	Oct 14, 2024, 2:59:36 AM	WIP
🟢 @MartinKavik	Oct 14, 2024, 1:33:49 PM	WIP
🟢 @cajun-code	Oct 14, 2024, 3:21:58 PM	WIP
🟢 @anchalshivank	Oct 14, 2024, 4:00:08 PM	WIP
🟢 @mcargille	Oct 14, 2024, 5:43:16 PM	WIP
🟢 @igorperic17	Oct 16, 2024, 5:12:19 AM	WIP
🟢 @born2ngopi	Oct 17, 2024, 6:16:37 AM	WIP
🟢 @debaa98	Oct 19, 2024, 12:17:09 PM	WIP

volfcan commented 1 week ago

/attempt #1004

Options

Cancel my attempt

kumarvivek1752 commented 1 week ago

/attempt #1004

Options

Cancel my attempt

kvpan commented 1 week ago

/attempt #1004

Options

Cancel my attempt

nickconway commented 1 week ago

/attempt #1004

Options

Cancel my attempt

cmwelsh commented 1 week ago

/attempt #1004

Options

Cancel my attempt

uurl commented 1 week ago

/attempt #1004

Options

Cancel my attempt

jdegoes commented 6 days ago

I have uploaded a new version of the Initial File System specification.

There are two corrections:

file-path instead of body. In several places, body was used instead of file-path for the return of the Rib script for the route binding. Now, the document consistently uses file-path as the field containing a string that identifies the path of the file to serve for the file-server binding type.
Variation Clarification. The specification requested supporting a result type in the Worker Gateway for the Rib script for file serving route bindings. However, it did not clarify why or under what circumstances this alternative should be supported. The revised specification clarifies that, as an alternative to returning a record with a file-path, the script may return a simple string, potentially wrapped in result, which identifies the file path--as a shortcut for developers.

Initial File System Spec v2.pdf

MartinKavik commented 6 days ago

/attempt #1004

Options

Cancel my attempt

cajun-code commented 6 days ago

/attempt #1004

Options

Cancel my attempt

anchalshivank commented 6 days ago

/attempt #1004

Options

Cancel my attempt

mcargille commented 6 days ago

/attempt #1004

Options

Cancel my attempt

camsteffen commented 6 days ago

The example golem manifest shows the source file path (or url) and permissions for each file. I think a third field is needed for the path of the file in the worker, perhaps named target_path?

jdegoes commented 6 days ago

@camsteffen Yes, which suggests that perhaps path should be renamed to sourcePath.

I will incorporate these updates into a v3 of the spec.

jdegoes commented 6 days ago

I have uploaded a new version of the Initial File System specification.

There is one clarification identified as being necessary by @camsteffen:

sourcePath versus targetPath. The spec only contained sourcePath information for files in the initial file set. However, as the files as located in the user's local file system or at various remote URLs is arbitrary, the user must be free to create their desired structure for the initial file system. So now both sourcePath and targetPath may be specified. In a common case, sourcePath will be a directory, and targetPath will be root (/).

Initial File System Spec v3.pdf

igorperic17 commented 5 days ago

/attempt #1004

Options

Cancel my attempt

born2ngopi commented 4 days ago

/attempt #1004

Options

Cancel my attempt

camsteffen commented 3 days ago

In a common case, sourcePath will be a directory, and targetPath will be root (/).

I had interpreted the spec as only allowing individual files in the yaml. But it sounds like you are expecting that a directory may be added, and thus including any contained files recursively?

jdegoes commented 2 days ago

@camsteffen Yes, indeed, you should allow specifying local directories (I think that will be far more common than specifying individual files).

jorgehermo9 commented 2 days ago

Hi @jdegoes

I the spec, the golem.yaml file is specified to contain only one component definition

component:
 name: component-abc
 ...
 properties:
 files:
 - sourcePath: ./a.txt
 targetPath: /a.txt
 permissions: read-only
 - sourcePath: ../../b.dat
 targetPath: /b.dat
 permissions: read-write
 - sourcePath: https://foo.com/bar?baz=quux
 targetPath: /bar.html
 permissions: read-only

But in the PR that introduced the declarative build https://github.com/golemcloud/wasm-rpc/pull/85#issue-2545101008 the components in the file are specified as an array of components in the form of

spec:
  components: 
    # Array of component definitions

and also, there are various kind of component type (for example, wasm-build components). I assume that the one which would refer this issue is to wasm component types.

My question is if we should use the file golem.yaml containing an array of components for the golem-cli component add command, because then, we should search withing the golem.yaml file inside spec.components array property, a component that matches wasm type and the same component name we are adding with the command.

It is subtly different from what you depicted in the specification PDF, as in that PDF it seems that a golem.yaml file is attached to a single component and it's not.

debaa98 commented 1 day ago

/attempt #1004

Options

Cancel my attempt

jdegoes commented 1 day ago

@jorgehermo9 In OAM, the component spec is an independent spec from the app spec; however, the component spec is embedded into the app spec. While the example only showed "component YAML", it is expected that golem-cli will be able to read and process the same YAML file that wasm-rpc reads and processes; and that the only difference will be each tool cares about slightly different parts of the overall YAML file.

golemcloud / golem