Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] No jobs defined in 'jobs' #1040

Open
thany opened this issue May 11, 2020 · 7 comments
Open

[BUG] No jobs defined in 'jobs' #1040

thany opened this issue May 11, 2020 · 7 comments
Labels

Comments

@thany
Copy link

thany commented May 11, 2020

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
Capture

** 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.

@thany thany added the bug label May 11, 2020
@orta
Copy link
Member

orta commented May 12, 2020

No jobs defined in 'jobs' means your workflow yml is not set up right, I'd look at that

@thany
Copy link
Author

thany commented May 13, 2020

I literally copypasted the YML from the Getting Started page.

This one, to be exact:
Capture

If that's not good, or outdated, maybe someone should give it an update.

@orta
Copy link
Member

orta commented May 13, 2020

yeah, looks like the formatting is getting chewed up there 👍

@thany
Copy link
Author

thany commented May 13, 2020

I don't know. Is it? I'm not familiar with YML formatting.
Should say something after jobs: I suppose? I can understand why jobs is empty that way...

Also still don't understand where that GITHUB_TOKEN comes from, or if I should worry about it at all. It's totally unclear from the docs what that is, what it's for, and if I should do anything about it.

It's also still not clear why I've created an additional account. It's not being used, as far as I can tell.

@fbartho
Copy link
Member

fbartho commented May 14, 2020

@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

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

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.

@thany
Copy link
Author

thany commented May 19, 2020

@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?

@fbartho
Copy link
Member

fbartho commented May 19, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants