I couldn't get heroku:24 to work, but I was able to build .NET 10 with

pack build $CONTAINER --buildpack paketo-buildpacks/dotnet-core --builder docker.io/paketobuildpacks/ubuntu-noble-builder-buildpackless  --env BP_DOTNET_PROJECT_PATH=./$TARGET

where $CONTAINER is the name of my container and $TARGET the directory it is in

Things seem to be working a lot better now. Thanks for your help in getting my C# bots to run.

toolforge jobs logs

seems to be working satisfactorily too.

(1) Yes, I removed the output and error logging to get the jobs working again. It does indeed seem to have been the problem. Possibly the path is not defined? Does it work for you? It worked when I ran the job manually, but not from the cron run. Error messages like the one you got would be extremely useful to me. I can run the bots from containers on my own machines, but it is not the same as the Toolforge.

Part of the problem is the

Output log:    logs/conflicts.stdout.log

This does not work, and likely causes the job to error.

I tried running the one-off job (aclass3) today, and it went from "Pending" to "Pod in 'Pending' phase. State 'waiting'. Reason 'ContainerCreating'" in less than 20 seconds and ran in 14 seconds. So well done!

This is what it looks like:
tools.milhistbot@tools-bastion-15:~$ toolforge jobs list

+---------------+-------------------------+------------------------------------------+
|   Job name:   |        Job type:        |                 Status:                  |
+---------------+-------------------------+------------------------------------------+
|    aclass3    |         one-off         |           Running for 1h20m42s           |
|    aclass     |  schedule: 20 * * * *   |           Running for 1h3m34s            |
|    aclass2    |  schedule: 35 0 * * *   | Last schedule time: 2025-09-24T00:35:00Z |
| announcements |  schedule: 50 0 * * *   |            Running for 33m30s            |
|    archive    |  schedule: 10 15 1 * *  |        Waiting for scheduled time        |
|  autocheck2   |  schedule: 45 12 * * *  | Last schedule time: 2025-09-23T12:45:00Z |
|   autoclass   |  schedule: 45 2 * * *   | Last schedule time: 2025-09-23T02:45:00Z |
|  autoreport   |  schedule: 10 0 1 * *   | Last schedule time: 2025-09-01T00:10:00Z |
|    awards     |  schedule: 30 0 * * *   |            Running for 53m19s            |
|   conflicts   |  schedule: 45 4 * * *   |        Waiting for scheduled time        |
|      fac      | schedule: 05 0,12 * * * |           Running for 1h18m34s           |
|     fanmp     |  schedule: 35 0 * * *   |            Running for 48m34s            |
|      far      | schedule: 15 0,12 * * * |           Running for 1h8m34s            |
|      flc      | schedule: 25 0,12 * * * |            Running for 58m33s            |
|  membership   |  schedule: 10 1 16 * *  |        Waiting for scheduled time        |
|    reviews    | schedule: 30 0 2 */3 *  |        Waiting for scheduled time        |
|     stats     |  schedule: 10 2 7 * *   |        Waiting for scheduled time        |
|     stubs     |  schedule: 45 3 * * *   |        Waiting for scheduled time        |
|      tfa      |  schedule: 45 0 * * *   |            Running for 38m35s            |
+---------------+-------------------------+------------------------------------------+

None of these jobs takes more than a few minutes to run! All of them listed as "Running" are stuck in "pending" phase.

This was not just one job, it was all the MilHist jobs, and they were in the pending state for a very long time before they were killed by the admin or some automated process. This particular job normally takes less than one minute to run. Here it was waiting over half an hour just to start! Something is very wrong.

I ran a toolforge build clean. I then rebuilt all the images. Now using 86% of the 1 Gi quota, which means space is running short already!

I had the problem with {{PD-USGov-Army}}. Worked around it by checking the US gov box, then later changing the licence from {{PD-USGov}} to {{PD-USGov-Army}}

In some cases this is failing to provide an edit interlanguage links option even if the Wikidata item does exist!!! When I created the English language article "Catharina Weiss", there was a Wikidata entry "Catharina Weiß" which listed "Catharina Weiss" under "also known as" but still it could not find it! Replace with the simpler dialogue as is used in Vector 2010. I don't want to have to switch to Vector 2010 just to add interlanguage links. (Although it is preferable to using Wikidata.)

The jobs.yaml file now reads:

# autocheck2
- name: autocheck2
  command: launcher web -ff -n=1000
  image: tool-milhistbot/autocheck:latest
  schedule: "45 12 * * *"
  emails: onfailure
  mount: all

That's exactly what I did. I used envvars list to hold the password:

• Job 'autocheck2' (cronjob) (emails: onfailure) had 2 events:
  • Pod 'autocheck2-28678365-b2wv7'. Phase: 'running'. Container state: 'terminated'. Start timestamp 2024-07-11T12:45:38Z. Finish timestamp 2024-07-11T12:45:40Z. Exit code was '134'. With reason 'Error'.
  • Pod 'autocheck2-28678365-b2wv7'. Phase: 'failed'. Container state: 'terminated'. Start timestamp 2024-07-11T12:45:38Z. Finish timestamp 2024-07-11T12:45:40Z. Exit code was '134'. With reason 'Error'.

Oh. Thanks for that. I am not in the habit of calling the main program Program.cs (the default) because I usually build more than one in the same solution. Having a separate project in toolforge means this is not an issue.

I find it strange that you are looking for the Program.cs file rather than the *.csproj file, which would seem more logical.

It seems to be working now:

Aargh. Error on my part. I will check in a version that reports errors better.

I have no access to podman on your server, but I can run locally on my own.

I attach a copy of the build output.

tools.milhistbot@tools-sgebastion-10:~$ cat milhistbot-liftwing/Procfile
web: heroku_output/Liftwing

@JJMC89 That seems correct.

That's what it says, but it is giving me an error message saying it does not exist:

Making some progress.

The documentation says to become milihistbot and run the build from there

@bd808 Thanks for that. I will ensure that there is a Program.cs element in the top level of the repository.

I don't quite understand this.

@bd808 I can confirm that it is working now. Thanks for your assistance in resolving this problem.

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)

I tried logging in to gitlab as Ross Mallett at

Be that as it may,

My Gitlab account is working.

When I try to use the admin console (https://toolsadmin.wikimedia.org/tools/id/milhistbot/repos/create) to create a new repository it says:
No GitLab accounts found for tool maintainers.

As you say, the biggest obstacle is that there is no dotnet buildpack available.

Using a dotnet buildpack is fairly simple. eg.:
$ pack build liftwing --buildpack paketo-buildpacks/dotnet-core --builder paketobuildpacks/builder:base --env BP_DOTNET_PROJECT_PATH=./Liftwing
$ docker run liftwing "Hanford Engineer Works" 2>/dev/nul
Setting ASPNETCORE_URLS=http://0.0.0.0:8080
FA

@komla Sorry, I was away and did not see your comment until now. A build pack will not work for me they way you are trying. I have multiple C# projects in the one git repository. It was never intended to be built in this manner. It will simply give you an error telling you that it does not know what project to build, and there is no workaround for this.

Tool has been migrated to using the kubernetes containers. However the task to create a proper dotnet build environment is still outstanding

Best practice for containers is for each app to have its own. It is regarded as an error to use them like virtual machines. See https://cloud.google.com/architecture/best-practices-for-building-containers

An alternative would be to install the latest version of dotnet

Confirmed that my executables run on the docker container.

Well done.

The documentation says: "The package ca-certificates-mono should be installed to get SSL certificates for HTTPS connections. Install this package if you run into trouble making HTTPS connections."

I have edited the request. I created it as a feature, not a bug report.

We use Rocky 9 here. All software here is patched an kept up to date due to the threat from foreign-government-sponsored hackers and ransomware attacks.

You're quite right; MIME::Lite is not available on the Grid. We never needed it there because we had sendmail and later exim.

I do have a workaround: I could use Net::SMTP. This is a low-level module, but it is included with a standard Perl 6.32 install.I have tested this with the tf-perl532 image. Using it would require me to write an new email wrapper for my bots to use. Currently my wrapper supports sendmail, exim and MIME::Lite.

Perl has a mail module, MIME::Lite, but while it is available on the Grid, it has not been provided in the Kubernetes image.

I've created a new feature suggestion T320904.

MIME::Lite is not installed on perl532-tf so no ability to send mail from that container

Garbage. The change to the documentation does not explain how to send an email if there is no sendmail, no exim, no MIME::Lite.

Not working. exim does not seem to work inside kubernetes containers. So I am not being informed if there is a problem. May have to revert.

Having the same problem as Ghuron

No good. Does not have msbuild.

All my Perl jobs are now migrated to Kubernetes. That leaves only the four C# ones.

How do you create an interactive shell on this container?

Running a web service would require a an external web server. It is not part of mono.

I guess this means that this can be closed, as I have a workaround of using the Ross Mallett account.

Does the move to gitlab mean that we can use ssh again instead of https?

It clearly shows Ross Mallett and Hawkeye7 are the same identity.

I can apparently log in as Ross Mallett. No idea why that account was used.

I am there as Ross Mallett, but that is not my gitlab account, Hawkeye7 is.

Yes, it has moved to Gitlab so now I cannot upload to it. :(

I am not a member of my own project :(

I've updated four of the Perl jobs to run with the tf-perl532 image. If they run okay, I will convert the other jobs. But the C# jobs cannot be converted until a C# image is made available.

No access to my own project.

Not working. And my profile has a bum email with a spelling error in it. Cannot correct it. Cannot do a push with gitlab. Please migrate back.

The tool contains scripts written in Perl; these should be okay for now, but I switched away from them when WMF started talking about OpenAuth, which the Perl MediaWiki::Bot does not support. These I can migrate right now.

Something has gone wrong. My attempt to do a git push results in fatal: unable to access 'http://phabricator.wikimedia.org/source/tool-milhistbot.git/': The requested URL returned error: 403.

This is not currently possible. There is an outstanding request T311466 for the required docker image.

Closed but not resolved

Yes, I could do that but it is not my preferred option because:
(1) The module is currently available on the grid
(2) It defeats the purpose of having a perl container

My bots uses one Perl module that is not installed:
File::Slurp

msbuild is packaged with the latest release, so if you install the latest stable version (6.12.0)
(which you can get from https://www.mono-project.com/download/stable/#download-lin-debian)
it will be there!

Is there any way to test it?

It is there on the job grid and is used by my Perl bots.

A Perl container would need to have MediaWiki::Bot

Damn. msbuild is not installed on tools-sgebastion-10. So my Bots cannot be maintained.