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.

Okay. I have figured this out. Can close now.

It looks like tools-sgebastion-10 is an obsolete server that needs to be decommissioned. How do you force it to login to a working server?

rmallett@tools-sgebastion-07:~$ mono --version
Mono JIT compiler version 5.12.0.226 (tarball Thu May 3 09:49:46 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
GC: sgen (concurrent by default)
rmallett@tools-sgebastion-07:~$ which msbuild
/usr/bin/msbuild
rmallett@tools-sgebastion-07:~$

My Bots are written with a C# API. Still working so long as mono is present, but changing them will be difficult. Can rtebuild on the Linux machine here, but no assurance that iut is running the same version of mono.

No. xbuild does not contain the libraries that I need. Cannot build with xbuild. Need to have mono restored.

rmallett@tools-sgebastion-10:~/tool-milhistbot/mono$ xbuild AutoStub.csproj

rmallett@tools-sgebastion-10:~$ which mono
/usr/bin/mono
rmallett@tools-sgebastion-10:~$ which msbuild
rmallett@tools-sgebastion-10:~$ uname
Linux
rmallett@tools-sgebastion-10:~$ uname -a
Linux tools-sgebastion-10 4.19.0-20-cloud-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux
rmallett@tools-sgebastion-10:~$ hostname
tools-sgebastion-10
rmallett@tools-sgebastion-10:~$ dnsdomainname
tools.eqiad1.wikimedia.cloud
rmallett@tools-sgebastion-10:~$

mono is in /usr/bin/mono, and msbuild should be there too. Except that it is missing again. What is going on?

Toolforge. tools-sgebastion-10.

Hmmm. It is back now. Possibly a upgrade?

Okay, I have over to using https.

It seems that I do have a gitlab.wikimedia.org account, so the project could be moved there, although it says that it is still under construction.

HTTPS is for web pages. I am dealing with software, not web pages.

I'm not sure I understand what is proposed here... If Phabricator is not the authoritative place to host repositories, then what is? How is it proposed that I maintain my sources without git?