fix(vscode/devcontainer): unexpected exit stdout /etc/passwd #2404
Assignees
Labels
bug
Something isn't working
Developer_Experience
documentation
Improvements or additions to documentation
P2
Priority 2: High
Tests
Anything related to tests be that automatic or manual, integration or unit, etc.
Triage_Needed
Triage if the issue is/still relevant, bug report is valid, arch/design details etc.
Comments
petermetz
added
bug
|
I have a mostly working Dockerfile, the last issue with it is that an upgraded Fabric 2.x AIO image still cannot pass the tests because of this issue: packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> [2023-05-03T22:59:40.725Z] ERROR (DeployContractEndpointV1): DeployContractEndpointV1#handleRequest() failed to serve contract deploy request Error: All configured authentication methods failed
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at doNextAuth (/workspaces/cacti/node_modules/ssh2/lib/client.js:803:21)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at tryNextAuth (/workspaces/cacti/node_modules/ssh2/lib/client.js:993:7)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at USERAUTH_FAILURE (/workspaces/cacti/node_modules/ssh2/lib/client.js:373:11)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at 51 (/workspaces/cacti/node_modules/ssh2/lib/protocol/handlers.misc.js:337:16)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Protocol.onPayload (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol.js:2025:10)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at AESGCMDecipherNative.decrypt (/workspaces/cacti/node_modules/ssh2/lib/protocol/crypto.js:987:26)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Protocol.parsePacket [as _parse] (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol.js:1994:25)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Protocol.parse (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol.js:293:16)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Socket.<anonymous> (/workspaces/cacti/node_modules/ssh2/lib/client.js:713:21)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Socket.emit (node:events:513:28)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Socket.emit (node:domain:489:12)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at addChunk (node:internal/streams/readable:315:12)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at readableAddChunk (node:internal/streams/readable:289:9)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at Socket.Readable.push (node:internal/streams/readable:228:10)
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> level: 'client-authentication'
packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 2> }
FAIL packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 1 failed of 3 2m
✖ Error: Request failed with status code 500
|
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 3, 2023
WORK IN PROGRESS
There's still an issue with running the tests
of the fabric connector where the 2.x
AIO image is working (healthcheck OK)
but the test case fails with at the contract
deployment part with this:
[2023-05-03T22:59:40.725Z] ERROR (DeployContractEndpointV1):
DeployContractEndpointV1#handleRequest() failed to serve contract deploy
request Error: All configured authentication methods failed
at doNextAuth (/workspaces/cacti/node_modules/ssh2/lib/client.js:803:21)
at tryNextAuth (/workspaces/cacti/node_modules/ssh2/lib/client.js:993:7)
at USERAUTH_FAILURE (/workspaces/cacti/node_modules/ssh2/lib/client.js:373:11)
at 51 (/workspaces/cacti/node_modules/ssh2/lib/protocol/handlers.misc.js:337:16)
at Protocol.onPayload (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol.js:2025:10)
at AESGCMDecipherNative.decrypt (/workspaces/cacti/node_modules/ssh2/lib/protocol/crypto.js:
987:26)
at Protocol.parsePacket [as _parse] (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol
.js:1994:25)
at Protocol.parse (/workspaces/cacti/node_modules/ssh2/lib/protocol/Protocol.js:293:16)
at Socket.<anonymous> (/workspaces/cacti/node_modules/ssh2/lib/client.js:713:21)
at Socket.emit (node:events:513:28)
at Socket.emit (node:domain:489:12)
at addChunk (node:internal/streams/readable:315:12)
at readableAddChunk (node:internal/streams/readable:289:9)
at Socket.Readable.push (node:internal/streams/readable:228:10)
at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {
level: 'client-authentication'
}
FAIL packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/
fabric-v2-2-x/deploy-cc-from-golang-source.test.ts 1 failed of 3 2m
✖ Error: Request failed with status code 500
Fixes hyperledger#2404
Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 5, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
sandeepnRES
pushed a commit
to petermetz/cacti
that referenced
this issue
May 8, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
sandeepnRES
pushed a commit
to petermetz/cacti
that referenced
this issue
May 9, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 10, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 10, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
sandeepnRES
pushed a commit
to petermetz/cacti
that referenced
this issue
May 19, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
May 22, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Jun 14, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Jun 14, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Jun 15, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Jun 15, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. 8. Also added a publishing workflow action that will build the dev container image on the main branch when there is a release tag (v*) issued. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
that referenced
this issue
Jun 16, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. 8. Also added a publishing workflow action that will build the dev container image on the main branch when there is a release tag (v*) issued. Fixes #2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
barnapa
pushed a commit
to barnapa/cacti
that referenced
this issue
Jun 22, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. 8. Also added a publishing workflow action that will build the dev container image on the main branch when there is a release tag (v*) issued. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
sandeepnRES
pushed a commit
to sandeepnRES/cacti
that referenced
this issue
Dec 21, 2023
1. Moved away from trying to handroll an Ubuntu-22.04 image for the dev container and instead used the "features" feature (no pun intended) of the dev container spec: https://code.visualstudio.com/blogs/2022/09/15/dev-container-features 2. This produces a container that builds and launches reliably without the issues the previous version was suffering from (which was that to some people the container would just exit randomly during the launch) 3. Our future goal of having the dev container being built in a reproducible way is still not achieved, but we've gotten closer because in the meantime while working on this issue it was discovered that we can re-build the images directly from the CLI by using the dev container CLI package: https://github.com/devcontainers/cli 4. The upside of not building the image from scratch is that we can count on future improvements/maintenance from others who are working on these images. 5. The downside of not building the image from scratch is that if we end up finding something that does not work due to the customizations, it might be more difficult to figure that out compared to if we had just build our own. 6. It is hard to predcit right now whether 4) or 5) will end up being having the stronger effect, but we can cross that bridge when we get to it. 7. In the meantime I've started working on a contribution to the dev container CLI itself for a dockerfile ejection feature (meaning that we'll be able to render a single Dockerfile for the dev container (that right now the CLI only stores/uses internally in it's own code at runtime). This eject feature will be good for debugging purposes in case anything goes wrong with the image in the future. 8. Also added a publishing workflow action that will build the dev container image on the main branch when there is a release tag (v*) issued. Fixes hyperledger#2404 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Sometimes the dev container fails to start (or it does start but crashes immediately - without any error)
To Reproduce
Not sure how to reproduce because I never could. People have been reporting it every now and then though.
Expected behavior
The dev container is a foundational peace to the contributor experience and so it should be quite stable.
Logs/Stack traces
TBD
Hyperledger Cactus release version or commit (git rev-parse --short HEAD):
mainbut also this has been an issue for many releases going back pre-1.0.0Additional context
We have bigger plans to run the CI via the dev container as well and so a refactor of the image is necessary because of that as well (right now the image wouldn't work on the GitHub workflow CIs)
The text was updated successfully, but these errors were encountered: