FTP is still one of the most common methods to upload files to your web server. So it's not surprising that there are (too) many GitHub actions for it. However, if you want to download some files (e.g. to backup/commit content that was edited online), you are mostly out of luck.
GitHub Actions can be a good choice for deploying an ASP.NET Core application to an Azure Web App Service if you have the code in a GitHub repository. You can even generate the GitHub Actions workflow directly from the Azure Portal. However, if your solution is not very simple, the generated workflow may not work correctly.
When I was looking into GitHub Actions, I found an example configuration for dependency caching that seemed wrong to me. It specified that a unique key for caching dependencies should be generated by hashing all files named package.lock.json in the repository. I would expect the *.csproj files to be used instead.
GitHub Actions provide a default GITHUB_TOKEN that can be used by steps in your workflow that require access to your GitHub repository. However, some actions require more permissions than others.
For quite some time I have been regularly publishing new blog posts every Friday morning. I have the code for my blog in a GitHub repository. Each unpublished blog post that I have prepared in advance is in its own branch. To publish it, I just need to merge it with the main branch, which triggers the GitHub workflow I set up to deploy the blog. But while this does not take much time, I finally decided to look for ways to automate this last step.
Most of my blog posts have an accompanying GitHub repository with sample source code. On average, I create one such new repository per week, and they all share most of their configuration options. I looked at several options for automating repository creation to speed it up and reduce the likelihood of misconfigurations due to human error. The option I liked best was GitHub CLI and its alias command.
Since the introduction of GitHub Actions there's often no need any more to use an external CI/CD service. After I moved my blog repository from BitBucket to GitHub it was time to move my continuous deployment configuration from CircleCI to GitHub Actions as well.