Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888

Closed
weshaggard opened this issue Dec 6, 2022 · 10 comments
Closed

The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888

weshaggard opened this issue Dec 6, 2022 · 10 comments
Assignees
@konrad-jamrozik
Labels
Central-EngSys This issue is owned by the Engineering System team. EngSys This issue is impacting the engineering system.

Comments

@weshaggard
Copy link
Member

weshaggard commented Dec 6, 2022 •
edited by konrad-jamrozik
Loading

Apparently, we do not declare an image to use for our prepare-pipeline template steps https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/pipelines/templates/steps/prepare-pipelines.yml which means it defaults to ubuntu-latest which recently moved from ubuntu-20.04 to ubuntu-22.04. This causes a break because our prepare-pipelines template depends on .NET 3.1 and ubuntu-22.04 no longer has that version of .NET on the image.

See https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2034849&view=logs&j=6b902995-b73d-5f5c-66fd-a7f66c857d2c&t=a1c457be-0fbe-5525-b6b0-ac3cf58f8d6c

You must install or update .NET to run this application.

App: /home/vsts/work/1/pipeline-generator/pipeline-generator
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '3.1.0' (x64)
.NET location: /usr/share/dotnet

The following frameworks were found:
  6.0.11 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  7.0.0 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=ubuntu.22.04-x64

There are a few issues we should fix here:

  1. We should update our template to be explicit about which OS we are using and pin to that, in this case ubuntu-22.04 should probably be the image.
  2. We should update our tools to a later version of .NET, probably .NET 6.0 because .NET 3.1 is going out of support later this month.
@ghost ghost added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Dec 6, 2022
@weshaggard weshaggard added EngSys This issue is impacting the engineering system. Central-EngSys This issue is owned by the Engineering System team. and removed needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. labels Dec 6, 2022
@konrad-jamrozik
Copy link
Contributor

konrad-jamrozik commented Dec 6, 2022 •
edited
Loading

@weshaggard could we go straight for .NET 7.0, for all the language goodies etc.? End of support in May 14, 2024 as compared to .NET 6.0 November 12, 2024.

@weshaggard
Copy link
Member Author

There are a few blocking issues with the .NET 7.0 toolset currently which is why I'm hesitant to move to that just yet. See Azure/azure-sdk-for-net#32814 for some of those details.

@konrad-jamrozik
Copy link
Contributor

konrad-jamrozik commented Dec 8, 2022 •
edited
Loading

For reference: The image update of ubuntu-latest to Ubuntu 22.04 is mentioned in actions/runner-images#6399. This image has both net6.0 and net7.0, per its installed software page. The migration to Ubuntu 22.04 is mentioned from Ubuntu 20.04 software page, in turn mentioned in Microsoft-hosted agents doc, in turn mentioned in "pool" YAML schema definition doc and also in 1ES hosted pools doc on MMS images (Microsoft-internal), for the entry Azure Pipelines - ubuntu-20.04 (MMSUbuntu20.04).

This was referenced Dec 8, 2022
Closed
Merged
Merged
Merged
Closed
Closed
Merged
ghost pushed a commit that referenced this issue Dec 12, 2022
Introduce "job" version of prepare-pipelines.yml, with "pool" defined…
1e7a3a9 
… to use Ubuntu 20.04 (#4930)

This PR, in tandem with PRs #4915 and #4916, addresses #4888. This PR subsumes the abandoned PR of #4911.

Specifically, this PR ensures that `prepare-pipelines.yml` is configured to use specific `pool`, set to use Ubuntu 20.04:

```
pool:
  name: azsdk-pool-mms-ubuntu-2004-general
  vmImage: MMSUbuntu20.04
```

Without the [pool](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/pool?view=azure-pipelines) definition pointing to Ubuntu 20.04, the steps within the file used an implicit default, which resolves to `ubuntu-latest`. This caused breakage as explained in #4888. Setting the pool to Ubuntu 20.04 will allow us to:

- Immediately unblock the language repos `prepare-pipelines.yml` pipelines [1], as Ubuntu 20.04 has the .NET Core version used by it [2];
- Allow us to migrate our tooling to .NET 6 as both Ubuntu 20.04 and `ubuntu-latest`, which is Ubuntu 22.04 [3], have .NET on them [4]. This step is accomplished by PRs #4916 and #4915;
- Allow us to migrate to Ubuntu 22.04 once we migrate to .NET 6.

## Technical considerations of the changes

- The current `prepare-pipelines.yml` has only [steps](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/steps?view=azure-pipelines) definition, which does not support `pool` definition. One needs to wrap the steps in [job](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/jobs-job?view=azure-pipelines) definition to support `pool` [5].
- Because the `.yml` file is located in `eng/common/pipelines/templates/steps/` directory (note the `steps`), we cannot wrap the steps in job and leave it there; the introduction of `job` necessitates introducing the changes in `eng/common/pipelines/templates/jobs/` directory instead (note the `jobs`), which is done in this PR.
- Because this PR introduces a new file, once this PR is merged, the language-specific `prepare-pipelines.yml` language pipelines need to be rewired to point to the newly introduced file. This approach was proposed in #4911 (comment). 
  - Language repos PRs doing the rewiring: 
    Azure/azure-sdk-for-net#32999 
    ... more to come!

## Testing done

I have confirmed the proposed modification to the `.yml` file will work [by modifying the existing `prepare-pipelines.yml` directly](Azure/azure-sdk-for-java@f8cef4c) to have exactly the same contents as the `/jobs/prepare-pipelines.yml` introduced in this PR, and observing the [relevant build succeeds on azure-sdk-for-java](https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2044120&view=logs&j=7f42699e-eeb0-56c8-40c2-c88ae4093e4f&t=a02502cb-238e-5603-14ee-8bb7bd07f0c6):

![image](https://user-images.githubusercontent.com/4429827/206805076-b01baf33-871a-4ff2-816e-fa8458fa0063.png)

while it failed before this change:

![image](https://user-images.githubusercontent.com/4429827/206805129-b3bd8ebb-b97b-444b-8785-e6edf68c9720.png)

# Footnotes

[1] for example, [internal / java / prepare-pipelines](https://dev.azure.com/azure-sdk/internal/_build?definitionId=2158&_a=summary) pipeline, or [internal / net / prepare-pipelines](https://dev.azure.com/azure-sdk/internal/_build?definitionId=2179) pipeline.

[2] as evidenced by the [Ubuntu 20.04 image software page](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2004-Readme.md#net-core-sdk), it has .NET Core 3.1. The pool definition value points to a 1ES hosted image which has the software listed on that page, as explained by this comment: #4888 (comment).

[3] See this comment: #4888 (comment).

[4] as evidenced by the [Ubuntu 22.04 image software page](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#net-core-sdk).

[5] Observe that on [pool definition](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/pool?view=azure-pipelines) YAML reference page, we can read:

> Properties that use this definition: pipeline.pool, stages.stage.pool, jobs.job.pool, jobs.deployment.pool.

i.e. `steps.pool` is not listed.
This was referenced Dec 13, 2022
Merged
Merged
Merged
Merged
Merged
Merged
@konrad-jamrozik
Copy link
Contributor

Related work:

This was referenced Dec 15, 2022
Closed
Merged
@konrad-jamrozik
Copy link
Contributor

konrad-jamrozik commented Dec 18, 2022 •
edited
Loading

There are a few blocking issues with the .NET 7.0 toolset currently which is why I'm hesitant to move to that just yet. See Azure/azure-sdk-for-net#32814 for some of those details.

@weshaggard @benbp the underlying problem is now fixed, per:

However, the Ubuntu 22.04 image has .NET SDK 7.0.100 as of this writing, while .NET SDK 7.0.101 has the fix.

@konrad-jamrozik
Copy link
Contributor

konrad-jamrozik commented Dec 18, 2022 •
edited
Loading

@weshaggard @benbp I moved bulk of our tools to net6.0 in these PRs:

But there are few cases left. I wanted to check with you how to proceed with them. Especially given some of these tools might be obsolete, so perhaps I shouldn't spend time figuring out how to update, and instead delete them.

GHCreator

GHCreator uses netcoreapp3.1. I believe I would have to update the target in ghcreate repo, then make the drop, and update GHCreator config files in the tools repo.

Update 1/3/2023:

perf-automation

perf-automation appears to use netcoreapp3.1 for testing by default.

Update 12/20/2022: PR:

job-matrix

I see a lot of references to old .NET SDKs in the job-matrix tool. Not sure if anything needs to change here - do we perhaps want to drop some old versions, and add newer ones. like net6.0 ?

Update 12/28/2022: PRs:

This was referenced Dec 19, 2022
Merged
Merged
@benbp
Copy link
Member

benbp commented Dec 19, 2022 •
edited
Loading

@mikeharder re: updating the perf-automation test config

@konrad-jamrozik re: matrix, it doesn't need to change as it's a sample, but it seems better to me to keep it up to date regardless.

@jsquire are we still using ghcreator? We are getting dinged for out of date NET versions, but obviously can't expect Alex to update his repo that we get the dlls from.

@konrad-jamrozik konrad-jamrozik mentioned this issue Dec 19, 2022
Merged
konrad-jamrozik pushed a commit that referenced this issue Dec 20, 2022
Batch eng/common changes to wrap-up #4888 work: NuGet package update,…
ed13cce 
… obsolete file deletion, test restoration (#4988)

#4988
This was referenced Dec 20, 2022
Closed
Merged
Merged
Closed
Closed
@konrad-jamrozik konrad-jamrozik mentioned this issue Dec 28, 2022
Merged
@jsquire
Copy link
Member

jsquire commented Jan 3, 2023

using ghcreator? We are getting dinged for out of date NET versions, but obviously can't expect Alex to update his repo that we get the dlls from.

We can kill it.

Context:

We're currently only using it for label synchronization, which I need to rewrite to use the GH CLI at some point. Killing off GH Creator will give me a forcing function to prioritize doing so.

@konrad-jamrozik konrad-jamrozik mentioned this issue Jan 4, 2023
Merged
@konrad-jamrozik
Copy link
Contributor

@jsquire

I assume I cannot merge this PR until you replace usages of GHCreator to GH CLI. Please look at that PR to see what that entails. Search for https://github.com/Azure/azure-sdk-tools/pull/5042 in the list of changes to see all the places where GHCreator was being used, an thus needs to be replaced. Big thanks! :)

@konrad-jamrozik konrad-jamrozik mentioned this issue Jan 5, 2023
Open
@konrad-jamrozik konrad-jamrozik mentioned this issue Jan 20, 2023
Open
@konrad-jamrozik
Copy link
Contributor

I am closing this work item as completed. There is a follow-up work for this repo:

And for other repos:

@konrad-jamrozik konrad-jamrozik mentioned this issue Jan 24, 2023
Open
@konrad-jamrozik konrad-jamrozik mentioned this issue Apr 13, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@konrad-jamrozik konrad-jamrozik

Labels
Central-EngSys This issue is owned by the Engineering System team. EngSys This issue is impacting the engineering system.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jsquire @benbp @konrad-jamrozik @weshaggard