-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
feat: Add functionality for nix. Fixes #10998 #10999
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of new files at top-level. Is that necessary?
I believe I can probably refactor away the node-env.nix and node-package.nix by bringing some of that into flake.nix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requested changes (inline/comments)
Sorry @juliev0 and @terrytangyuan for my late engagement on this issue, was quite busy with another bug (#11102). |
New changes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM just left a minor comment. Thanks!
Should we move this to /hack folder instead of creating a dedicated one in root directory? |
@terrytangyuan I am happy to move it over if you think that is better, but I personally don't think it belongs there. The hack folder is specifically reserved for hacks that the Makefile uses, this is entirely separate from that so we shouldn't put it there imo. Is that alright? I'll chuck it in the hack folder otherwise. |
I feel like a |
@terrytangyuan I don't use devcontainers but I can ask someone who does (@Joibel ) to help me out as it does look like devcontainers does support the config in subdirectories: microsoft/vscode-remote-release#2413 |
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: isubasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: isubasinghe <[email protected]>
Signed-off-by: isubasinghe <[email protected]>
Signed-off-by: isubasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]>
For autodiscovery of "this project has a devcontainer config" I think |
@isubasinghe Can you help look into why the build is failing after merge? https://github.com/argoproj/argo-workflows/actions/runs/5145625809/jobs/9263514577 |
If it is really this PR, the only source of error I can think of is this -> https://github.com/argoproj/argo-workflows/pull/10999/files#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52L1-R1 The only reason I can see is the Makefile changing, but that seems somewhat unlikely given the CI tests ran fine. Might just be a coincidence, looking into it now. |
It could also be the files.go actually, will fix ASAP. |
@terrytangyuan here you go, it was missing a space : |
Signed-off-by: Isitha Subasinghe <[email protected]> Signed-off-by: isubasinghe <[email protected]>
Signed-off-by: Isitha Subasinghe <[email protected]> Signed-off-by: isubasinghe <[email protected]> Signed-off-by: Jeremy Hager <[email protected]>
Please see #10998 for a detailed comment regarding why this is needed.
This is a change from our fork that I ported to the upstream repo because it works quite well.
The steps to run Argo now are quite simple, and guaranteed to work exactly the same on every machine.
Not only this, the entire Argo build system is isolated from the rest of the user's filesystem.