Page MenuHomePhabricator

[builds-builder] Investigate how to enable mono/dotnet/c# and implement the best one to unblock us to migrate tools
Closed, ResolvedPublic

Description

The two options to look into are:

What will be done:

  • Upgrade the builder to the latest supported one (heroku/builder:22), that has the latest lifecycle image.
  • Use the lifecycle image from the builder
  • Inject buildpacks before the detect step
  • Add the jincod/dotnetcore-buildpack third-party buildpack to be injected too
  • Enjoy and rejoice

All this with an eye on T352389: [tbs][builder] Explore adding support for third-party buildpacks.

Event Timeline

dcaro updated the task description. (Show Details)
dcaro changed the task status from Open to In Progress.Dec 6 2023, 10:22 AM
dcaro claimed this task.
dcaro moved this task from Next Up to In Progress on the Toolforge (Toolforge iteration 02) board.

Looking into changing the builder image depending on the code language found some things that need sorting out:

  • Aptfile, nodjes, etc. will not work for the new builder (as those buildpacks are for the heroku one)
  • We need to know the language we are going to build for, this means one of two:
    • Checking at the builds-api level, this means having to probe the code from the builds-api (downloading the git repo/etc.)
    • Checking at the task level, this seems to be doable in two ways:
    • Checking at the builds-cli level, this would be forcing the user to pass a parameter for this type of builds, something we want to avoid

For the option of injecting the buildpack as we do with others, we would need to add it to the script https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/blob/main/deployment/chart/scripts/inject_buildpacks.sh?ref_type=heads

We could try to generalize it somehow too, though given the lack of impact on the user side and this blocking users from migrating I would do that as a second step (unless it's simple and/or considerably simplifies the script).

I think I'll start working on the latter, specially given that we want to re-think the way we do multistack and such.
Unless anyone has a better idea on making the first option quick and easy, cc. @Slst2020 @Raymond_Ndibe ?

For the option of injecting the buildpack as we do with others, we would need to add it to the script https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/blob/main/deployment/chart/scripts/inject_buildpacks.sh?ref_type=heads

We could try to generalize it somehow too, though given the lack of impact on the user side and this blocking users from migrating I would do that as a second step (unless it's simple and/or considerably simplifies the script).

How would we bypass the detect lifecycle stage failure? So far, we've only been injecting additional buildpacks, so there's always been one builder-supported primary language detected.

For the option of injecting the buildpack as we do with others, we would need to add it to the script https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/blob/main/deployment/chart/scripts/inject_buildpacks.sh?ref_type=heads

We could try to generalize it somehow too, though given the lack of impact on the user side and this blocking users from migrating I would do that as a second step (unless it's simple and/or considerably simplifies the script).

How would we bypass the detect lifecycle stage failure? So far, we've only been injecting additional buildpacks, so there's always been one builder-supported primary language detected.

Good point :), let me investigate.

I think that we can try the following:

  • Before the detect step
    • create a combined order.toml, with the builder provided one as base and adding the new base buildpacks and store it in a temporary volume
    • copy the builder buildpacks into a new buildpack directory (also in a temp volume) and download there the new base ones
  • In the detect phase, pass the CNB_ORDER_PATH and CNB_BUILDPACKS_DIR (https://github.com/buildpacks/spec/blob/main/platform.md#detector) pointing to the new ones
  • Then inject the nodejs static build one (as that one has to be done after)

This might open the door also to allowing users using project.toml or similar to specify multiple buildpacks (we would need to change the the pre-detect script to read that file and download + inject those in the order.toml).

Let me check if the detect custom paths + temp volume would work or not.

This is proving a bit more difficult than expected.

I was able to inject the buildpacks correctly, but the third-party dotnet buildpack is not cloud-native compatible, and as such, it can't be used on tekton (or even the pack cli) as it requires some of heroku's platform magic from before when they started adopting the cloud-native standards.

Tried using the paketo one directly with the heroku builder with no luck xd

I'm trying to see if I can modify it to be CNB compatible, will give up if it takes too much time.

I was able to migrate it to cnb, still have to test it works as expected in tekton, but with pack it builds correctly.

Sent upstream PR https://github.com/jincod/dotnetcore-buildpack/pull/189

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:22:37Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-admission (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:23:08Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-admission (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:28:27Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-admission (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:28:59Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-admission (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:35:31Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:36:02Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:42:56Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T13:43:29Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

dcaro updated the task description. (Show Details)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:22:56Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:23:12Z] <wm-bot2> dcaro@urcuchillay END (FAIL) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=99) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:24:32Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:25:01Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:36:09Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-11T15:36:42Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

To be able to specify the project file to build though we have to pass PROJECT_FILE as an environment variable, so that feature will depend on T338142: [toolforge-envvars.api,toolforge-build.api] Support using custom environment variables at build time

Normally, a Dotnet project has the solution file (.sln) at the top level and multiple project files (.csproj) in the directory below. If I could create a repo, I could create one with a solitary csproj file at the top level and then this would be nice but not necessary. Unfortunately, I cannot create a repo at the present time (T353176)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-12T12:12:31Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-12T12:13:03Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-12T12:16:32Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-12T12:17:06Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

dcaro changed the task status from In Progress to Stalled.Dec 12 2023, 1:13 PM
dcaro changed the task status from Stalled to In Progress.

project_1317_bot_df3177307bed93c3f34e421e26c86e38 opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/155

builds-api: bump to 0.0.117-20231213110249-3c9d6b72

project_1317_bot_df3177307bed93c3f34e421e26c86e38 opened https://gitlab.wikimedia.org/repos/cloud/toolforge/toolforge-deploy/-/merge_requests/156

builds-builder: bump to 0.0.81-20231213135909-70531772

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:12:02Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-builder (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:12:36Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-builder (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:12:46Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:13:14Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:22:03Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:22:33Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-api (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:22:41Z] <wm-bot2> dcaro@urcuchillay START - Cookbook wmcs.toolforge.k8s.component.deploy for component builds-builder (T352774)

Mentioned in SAL (#wikimedia-cloud-feed) [2023-12-13T14:23:13Z] <wm-bot2> dcaro@urcuchillay END (PASS) - Cookbook wmcs.toolforge.k8s.component.deploy (exit_code=0) for component builds-builder (T352774)

dcaro moved this task from In Review to Done on the Toolforge (Toolforge iteration 02) board.