remove Helix scripts from docker images

[wfurt]

This should not be needed with https://dev.azure.com/dnceng/internal/_workitems/edit/10192/ completed.
Essentially, Helix simply executes work inside the container but it stays outside of it.
https://dev.azure.com/dnceng/internal/_workitems/edit/8779 was my test to verify that we can execute tests in vanilla containers. We still need user and home for now.

This may break anyone who implicitly depends on packages that were borough in by the Helix fragments.
I'm not aware of any but when that happens I feel the right fix is to add them to the list as we would normally do.

This is big change so I'm wondering if there is good way to test it beyond what I did so far.
Any thoughts on this @lbussell @mthalman @richlander ???

[mthalman]

This is big change so I'm wondering if there is good way to test it beyond what I did so far.

What have you done for testing so far? What are you looking to have as the scope for your testing? The options would be:

• Build an image locally and push to your own ACR. Run a test build referencing the image from that ACR.
• Create a new temporary Dockerfile with the modified changes and assign it a new tag. Merge those changes in this repo and get the image published. Run a test build referencing the image from that ACR. Once verified, apply the changes to the original Dockerfile and remove the temp Dockerfile.

[mthalman]

Is it still necessary to have helixbot user?

[wfurt]

yes, it is at the moment. More changes coming to Helix but for now the uid 1000 is important for everything to work.

[wfurt]

While Helix itself is fine, this is blocked on Arcade reporter at the moment. dotnet/arcade#16775

[wfurt]

• Build an image locally and push to your own ACR. Run a test build referencing the image from that ACR.

Do we have anything we use for staging or testing? If not, I can check if I can create something under Helix staging subscription. I know how to update the runtime, but where/how would I change the container build?

[mthalman]

I know how to update the runtime, but where/how would I change the container build?

You would build the Docker image locally and push to the ACR.

.\build.ps1 -Paths <path-to-Dockerfile-dir>
docker tag mcr.microsoft.com/<image-tag> <acr-name>.azurecr.io/<image-tag>
az login
az acr login -n <acr-name>
docker push <acr-name>.azurecr.io/<image-tag>

[richlander]

Where will the helix Python scripts be built and run in this proposed model?

[mmitche]

How does this affect downlevel servicing? What changes need to be made at a repo level to be ready for this change?

[wfurt]

There will be no Python scripts any more @richlander.
dotnet/arcade#16774 will need to be ported to all servicing bands and the repos will need to digest that @mmitche via dependency flow.
We will need to update the Python Helix runner to use the new portable result format and I'll add that logic (and tests) to the new AOT implementation once the base client is merged. (waiting for review)

[mmitche]

@wfurt So, what's the merge strategy for this? I assume we need to wait until all of the servicing changes have been made.