[BUG] No jobs defined in 'jobs'

Describe the bug Github says:

No jobs defined in jobs

On the details of a workflow/action that ran.

To Reproduce Steps to reproduce the behavior are the literal steps on Gettings Started. I had to fill in some gaps where it doesn’t tell me what to do:

1. Created a new branch where I added danger with NPM, and added a dangerfile.js.
2. Create an account. This was not clear to me. It doesn’t literally say to do that, only that one could optionally do that. Recommended apparently. So I did. I will not be sure why I did this at the end.
3. Created an access token with repo permission on the new account. Unclear why this is, or what it’s for.
4. Went on to Github Actions to create a new workflow. Again, this was not clear. It just said to do this “after your tests”, but we have no tests as a Github Action. They are part of the build process that executes on Azure. So I created a new “workflow” and called it danger.yml.
5. Because our project is not strictly a javascript project, I decided on the second YML file, because that’s what it recommends. So I pasted that in.
6. Then I had to notice that Github can only either commit to master (which isn’t allowed) or create a new branch for this yml file. Ugh. Tell me sooner, will you? So, I reperated this step after deleting the brach I created in step 1, and then re-did the changes from step 1. So I end up with a branch containing two commits. One containing the dangerfile.js & package(-lock) changes, and another commit for this yml file. The order of a good Getting Started is really important, for this exact reason.
7. Then it says something about having to enable GITHUB_TOKEN in the workspace. What workspace? VScode? Visual Studio? Or do you mean the github repo? I have no idea what it’s going on about. But it also says Github creates a GITHUB_TOKEN automatically, so I kind of shrugged and hoped that that’s indeed the case. I don’t know where to find it though, but hey, it promised that it’ll be created so all is jolly good, right? I sure hoped so.
8. And that should be it. Or at least the Getting Started is now practically over. I should verify my installation. Alright, I will. So I shall go to the Actions tab on Github and see two actions, apparantly. One for each commit. So it “kind of” works.
9. However on closer inspection, it actually doesn’t. The X’s in front of the two actions don’t tell a positive story. And on of the two, the latter one where I added the package(-lock) and dangerfile.js changes, fails. And failing it does, with the error message at the start of this issue.

Expected behavior I honestly don’t know what to expect. I’ve never worked with DangerJS, or with Github Actions, or with secret tokens. However, I would most definitely not expect an error such as the above. I would expect it to at least run its job. Execute the dangerfile.js, I suppose. And because I haven’t created a PR yet (the Getting started hasn’t instructed me to do so, as far as I could tell), I would expect it to succeed with flying colours, because there is no PR for DangerJS to complain on just yet.

I would try creating a PR that has an issue to see if DangerJS complains on it, but I would first like things to work. Or at least not spew out errors.

Screenshots

** Your Environment**

software	version
danger.js	10.2.0
node	12.16.3
npm	6.14.4
Operating System	Windows 10

Additional context A better Getting Started might help a LOT. Also I still don’t quite get why I had to create that new account. I did do it, but I haven’t been instructed to use it in any way yet, other than to generate that access token. Should I put that access token somewhere? If only the Getting Started would tell me the what to do more precisely. All along this document I had the feeling that it assumed I knew some magical invisible intermediate steps that have to be taken in order for the next steps to work properly.

Or maybe it’s just late and someone will point out some crucial thing I overlooked. Either way, thanks for this tool that looks to be awesome. I’m sure it will be.

[fbartho]

No offense, but the file in the Getting Started doc, shouldn’t that just work? This file should be virtually identical to anyone using Danger, if I’m not mistaken, since it appears to tell Github just to “execute Danger”, essentially.

Yes @orta and I agree (I’m interpreting his comments above, not trying to put words in his mouth). The first order problem is that the Documentation Formatter/Site mangled the Yaml Example File – that’s what he meant in his comment. That’s a bug with the Docs site that is less than ideal.

DangerJS existed well before Github Actions – and Github Actions is definitely still changing things regularly – they completely changed their definition file format this November when they “exited beta”. Additionally, Github Actions is structured for many many more use cases than just the things that DangerJS really applies to, so there are many ways to configure it, and many ways to wire DangerJS into it. We cannot (and I think should not) be your first source of documentation to understand Github Actions. We’re a tool that you can choose to use if you already understand the CI that you’re choosing to use (and Github Actions is just one of more than a dozen supported CIs). We wouldn’t want you to accidentally configure Github Actions in an expensive or broken way, but we literally cannot enumerate all the ways you might do that. Github owns that part of the experience.

That said, I know we all want our product to be beginner friendly. So I think we sincerely appreciate your sharing your onboarding experience here! At some point we’ll want to break this down into a series of actionable changes, and hopefully people in the community will have time to contribute to it.

[thany]

@thany – you need to look at the official Github Actions documentation to see the right formatting: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions

No offense, but the file in the Getting Started doc, shouldn’t that just work? This file should be virtually identical to anyone using Danger, if I’m not mistaken, since it appears to tell Github just to “execute Danger”, essentially.

Additionally, the GITHUB_TOKEN comes from Github Actions (in your setup) – it is automatically provided by Github, and DangerJS has been made to understand it exists for your convenience – Or you configure DANGER_GITHUB_TOKEN yourself as a “secret” that you provide manually in the Github UI for that repository. In that case you’d be making a Bot account for Github, and using a Personal Access Token with the appropriate permissions. – One page of GitHub documentation for secrets is here: https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets

Alright, thanks for clearing that up. Maybe the Getting Started should be more clear on this, too. Currently it just says “do this, do that, etc” without explaining why and what it’s for.

All of this is us sharing what we’ve learned about Github and how it works. I wouldn’t call myself a Github Expert – having never been an employee there.

That’s fair. I’m only assuming that if this project supports Github Actions, it is tested to work with it as well, so at least one of the authors has some knowledge of how to work it. I also assumed Github, and therefor Github Actions, is the primary place where Danger would be ran. So, Github Actions not working right, seemed to me like a pretty severe problem.

But it seems now that Danger was not primarily intended to work that way… If that’s the case (and that’s a big if, because I still don’t have a clear picture), then what else is the absolute way to get Danger to run for a Github project, if not Github Actions?