Registry Issue when creating registry as part of pre-deployment about azuretre-deployment HOT 7 CLOSED

@daemel what was the name you used for the "action" acr and what is your treid?
The two acrs are different and can't have the same name, so maybe this is the issue?

from azuretre-deployment.

@tamirkamara - do you have a link to the documentation on the naming between ACR and ACTION_ACR?

I've reviewed the documentation here https://microsoft.github.io/AzureTRE/using-tre/pipelines/ and https://learn.microsoft.com/en-us/azure/container-registry/container-registry-get-started-portal?tabs=azure-cli as instructed. I manually added ACTION_ACR as the workflow failed to login in the ACR until I added ACTION_ACR - the piece of code call that is in the deploy-reusable workflow

     COMMAND: "make bootstrap mgmt-deploy"
      ACTIONS_ACR_NAME: ${{ secrets.ACTIONS_ACR_NAME }}
      ACTIONS_ACR_URI: ${{ secrets.ACTIONS_ACR_URI }}
      ACTIONS_ACR_PASSWORD: ${{ secrets.ACTIONS_ACR_PASSWORD }}
      ACTIONS_DEVCONTAINER_TAG: ${{ secrets.ACTIONS_DEVCONTAINER_TAG }}

I've also found that when using the DeployTRE the workflow bootstrap never creates the ACR. That does seem to align with the documentation above as we are told to create it manually, but we are not given instructions on which Env variables to open. I documented this last week in this Issue microsoft/AzureTRE#2605

from azuretre-deployment.

My previous comment was meant to diagnose the issue - can you confirm if your ACR_NAME and ACTIONS_ACR_NAME have the same name?

As for the docs, we recently discovered that a page outlining what github secrets are needed was misplaces/lost. We have an item to tend to that so hopefully next time will be much easier.

from azuretre-deployment.

yes - ACR_NAME and ACTIONS_ACR_NAME are the same values. How are the 2 ACR's different when I only see one deployment? Moreover, testing with different names causes the workflows to fail at ACR login - a successful login only happens when the names are the same - please explain as the comments are not aligning with testing.

from azuretre-deployment.

Thank you for confirming.
The expectation is that the ACTIONS_ACR will be created by an admin before running any workflow. It's being described in #3 here: https://microsoft.github.io/AzureTRE/using-tre/pipelines/#setup-github-environment. I realize we can be maybe more explicit in the wording there saying it's different than the ACR_NAME (which is mentioned in the misplaced doc we're sorting) and can't have the same value.

Why is this required and the difference:

• The ACTIONS_ACR is used only in a CICD setting, and holds the dev container images. A developer doesn't need this one.
• The one in ACR_NAME is used by the TRE system to store all the images it needs for runtime (apps and bundles). This ACR is also created and managed by the TRE system itself.

I presume that you didn't have a successful login since you haven't created it before running the workflow, right?
But then, what did you put in the corresponding password secret?
Can you please help me understand better the scenario of when you have set 2 different values for the ACRs?

from azuretre-deployment.

I would contend that what you are describing is much more than a clarification as the explanation above contradicts instructions on the Prerequisites page https://microsoft.github.io/AzureTRE/tre-admins/setup-instructions/pre-deployment-steps/ and diagrams on the Architecture page - https://microsoft.github.io/AzureTRE/azure-tre-overview/architecture/

If you are viewing this as Dev vs non-Dev instructions, then please convey those distinctions on the documentation site as it is very confusing as it is now; the documentation site today (based on your explanation) intermingles both the Dev and Actions approaches.

Also, why 2 ACR's? An ACR can hold many different repositories, so why would we need 2 ACR's?

from azuretre-deployment.

The doc in https://microsoft.github.io/AzureTRE/tre-admins/setup-instructions/pre-deployment-steps/ is actually common step for both a manual/local and an automatic deployment. Due to the complexities in make auth I don't see this part changing.

I do recognize that the end of this document should have 2 options and let the reader make a choice between a manual/local deployment (make all and described here) or an automatic/cicd one (as described here plus the secrets doc we need to undelete).

I think the idea behind the 2 ACRs was to solve a chicken and an egg issue in our workflows design and how reusability works in github actions. I might have an idea on how to solve it but need to test and see if it works (probably only next week).

from azuretre-deployment.