Day-20 @ #309
Comments
|
Hello there, thanks for opening your first issue here. We welcome you to the #90DaysOfDevOps community! |
|
@asankov are you able to support |
|
I will take a look in the new few days. |
|
Sorry, Michael. Will take a look soon. Can you assign me to the issue, please? |
|
Still the same maybe because it MI environment issue. I would try it on full debian (ubuntu) and see if is the same. |
|
@Obasoro can you provide full error log? I see the error in the screenshot, but don't see the root cause. Maybe the full log will provide more info. Also, it would be good to describe your environment - OS, CPU, etc. so that we can raise this issue to upstream - https://github.com/rstatsinger/contrast-java-webgoat-docker |
|
@asankov I have attached the error log screenshot. |
|
@Obasoro I know that you attached the logs but I told you that I can't figure out the issue from these logs, because these are not the whole logs. There are more logs that are missing here. Please attach ALL logs after the invocation of ‘run.sh’. Also, please attach the logs as text, not as screenshot so that I can copy-paste from them. |
|
@asankov |
|
@Obasoro What is your environment - OS, OS version, CPU arch, etc? |
|
OS-Macbook Pro M1 chip |
|
I see. I think this is due to the Apple Silicon CPU. There is another issue on the upstream project that complains about the same things - rstatsinger/contrast-java-webgoat-docker#5 As a workaround, you can try running this on another machine (if you have one) or on a VM (local or in the cloud). |
|
Unfortunately, I don't have access to an M1 or M2 machine, so I cannot reproduce it or debug it further. We will have to wait for upstream to take a look at the issue and fix it. |
|
Thanks @asankov. Keep me update if the upstream work on it. Also, I would move to test it on WSL. |
|
I believe this can be closed now as there is a fix? Please confirm and I will close the issue. |
|
So far we would wait till there is a fix. I would keep trying/going back to it and checking for a possible solution. |
|
@MichaelCade, it does not look like there is any activity on the original issue - rstatsinger/contrast-java-webgoat-docker#5. Why did you think there is a fix? Did you saw something else? |
|
Sorry my bad there was another PR raised #375 but not related to this issue. |
|
Any update on this? |
|
There's no activity on the upstream issue. I actually have access to an M1 MacBook now, so I can try to reproduce it next week and see the results. |
title: Choosing who owns and pays for codespaces in your organization
OverviewIf you're the owner of an organization on a {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %} plan, you can pay for your members' and collaborators' usage of {% data variables.product.prodname_github_codespaces %}. Paying for usage will allow people to use {% data variables.product.prodname_github_codespaces %} to work in your repositories without having to do so at their own expense, and will give your organization more control over the codespaces created from your repositories. To pay for usage, you must do all of the following things.
About choosing who pays for codespacesPaying for a codespace means paying for the storage and compute costs of the codespace over the codespace's lifetime. For more information, see "AUTOTITLE." Organizations on a {% data variables.product.prodname_free_team %} plan cannot pay for {% data variables.product.prodname_github_codespaces %}, so the user who creates the codespace always pays. For organizations on a {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %} plan, when a user creates a codespace from a repository in the organization, either the user or the organization can pay for the codespace. The user who creates a codespace can't choose who pays for it, but the organization can choose to pay for certain users. In an organization's settings, you can choose for codespaces to be user-owned or organization-owned. If an organization chooses for codespaces to be user-owned, a user who creates a codespace from a repository in the organization always pays for the codespace. The user's access to create codespaces depends on the visibility of the repository and your organization's access settings. If an organization chooses for codespaces to be organization-owned, the organization will pay for a codespace if all the following things are true. {% data reusables.codespaces.when-an-org-pays %} For more information about enabling {% data variables.product.prodname_github_codespaces %} for members and collaborators, see "AUTOTITLE." {% ifversion ghec %} Note: If you own an {% data variables.enterprise.prodname_emu_org %}, and do not allow {% data variables.product.prodname_github_codespaces %} to be billed to your organization, members with {% data variables.enterprise.prodname_managed_users %} will not be able to use {% data variables.product.prodname_github_codespaces %}. For more information, see "AUTOTITLE." {% endnote %} About ownership of codespacesA codespace is paid for by the account that owns it. The codespace owner can be the user who created the codespace, or it can be an organization. If your organization owns a codespace, your organization has control over that codespace. For example, for codespaces owned by your organization, you can:
If a user owns a codespace, your organization does not have any of these options for managing the codespace, even if the codespace was created from one of your organization's repositories. When a user creates a codespace, they're told who will pay for it, and therefore who owns it. From a user's point of view, apart from the policies your organization can use to set constraints on codespaces, the experience with {% data variables.product.prodname_github_codespaces %} will be similar regardless of who owns a codespace. For example, most of a user's personal settings for {% data variables.product.prodname_github_codespaces %}, such as dotfiles, encrypted secrets, and GPG verification, apply regardless of who owns the codespace. About changing your settingsWhen you change your ownership settings, existing codespaces can transfer to a new owner. If you change from organization ownership to user ownership, codespaces that are currently owned by your organization will be transferred to the ownership of the user who created the codespace. Before you make this change, you should ask each user to review the codespaces that will be transferred to their ownership. These codespaces will now incur usage on the user's personal account. If you change from user ownership to organization ownership, existing codespaces may be transferred to your organization's ownership. A codespace will be transferred if the user who currently owns the codespace is a member or collaborator, and you have enabled {% data variables.product.prodname_github_codespaces %} for this user. Otherwise, a codespace will remain under the ownership of the user. Choosing who owns and pays for codespaces{% note %} Note: If you cannot access the option to make codespaces organization-owned, this may be because you have disabled {% data variables.product.prodname_github_codespaces %} for all users in your organization's private{% ifversion ghec %} and internal{% endif %} repositories. For more information, see "About choosing who pays for codespaces." {% endnote %} {% data reusables.profile.access_org %}
Setting a spending limit{% data reusables.codespaces.codespaces-spending-limit-requirement %} For information on managing and changing your account's spending limit, see "AUTOTITLE." |
I am getting this error whenever I try building the dockerfile or run.sh file
The text was updated successfully, but these errors were encountered: