Yes a malicious fork will NOT be able to get a JWT just like they are not able to get any other secrets or privledges to the repo.

I was going to ask for a source, but I saw you've commented in the past that you're the GitHub Actions product manager.

This looks like a great feature to help keep long-lived AWS secrets out of my builds entirely.

self-hosted runners can be deployed for an org as well https://github.blog/changelog/2020-04-22-github-actions-orga....

Huzzah! That’s great.

Hi, GitHub Actions product manager here.

Thanks for your interest in GitHub Actions. You can set a property `continue-on-error: true` for each step and the runner will ignore a failed result and continue the workflow. For more details on workflow configuration please see https://help.github.com/en/articles/workflow-syntax-for-gith...

Workflow runs can be triggered via a `repository_dispatch` event with a custom payload. Using this model you could create a tool to allow for manual triggering. However, we do expect to provide a more integrated experience for triggering manual runs with custom inputs.

More capabilities for actions to post artifacts and reports as part of our experience is absolutely on our radar.

We are working to bring as many new users into the beta as quickly as we can and we look forward to your feedback.

@nbevans could you provide a few more details here on the agent and where it is hosted? The agent itself does not rely on the IIS worker pool and we are not aware of any bugs in this area. If we have some we would love to get them addressed.

We really hate to hear you are having such a bad experience. The engineering manager has reached out on Twitter and included me. I would love to see what I can do to help

I personally don't really understand this approach. In fact, this approach annoys me.

In this situation I feel like the product has already wasted my time and now people are contacting me to waste more of my time.

The blog is really detailed and includes screenshots. You could fix the obvious issues and then follow up with an update once it's released.

In the opening paragraphs I stated it was my hope that this gives me a gateway to communicate with someone that isn't support and isn't the void that is their robot response issue tracker.

That said, they generously reached out to me and appear to genuinely be concerned by my experience. I plan to keep posting as I run into issues and also as they correct my mistakes and also solve my problems.

[PM on the Azure Pipelines team] The primary focus here is making the individual services easier for teams to adopt. Azure pipelines for CI/CD, Azure Boards for planning, etc. Those services support the overall goal of improving your DevOps practices.

I see that this is more than a rebranding and was just commenting with my immediate, fatuous response. I should save fatuous responses for reddit.

It adds some humor and unfortunately the lack of it can make HN seem like eating burnt toast at times.

Hi avsm,

We absolutely support building Windows Docker Images. At the moment you are limited to either Server 2016 or Server 1803 based images but that is something we are working on enhancing. I would be interested in understanding your needs at a deeper level. Please ping me on twitter @chrisrpatterson if you are interested.

Hi Chris,

What about building .NET /XAML client-rich apps on Windows, is that yet supported? We've tried VSTS before but it had some dependencies issues.

We fully support building those on our VS 2017 vm image. Building those inside of a container I do not believe is currently supported by Windows.

Azure Pipelines has all of the same features on VSTS Build and Release but adds an option for defining your CI pipeline in YAML (this feature was previously in preview).