-
Notifications
You must be signed in to change notification settings - Fork 481
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
Gitlab #299
Gitlab #299
Conversation
# The title of the Pull Request | ||
# @return String | ||
# | ||
def pr_title |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, these should move to the gitlab vernacular - mr_title
( documentation around this will be handled fine 👍 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless there's a need for a common interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, I don't think so, for Danger::RequestSources::GitLab
there should be, ( you could add method aliases though, so that people can C&P examples that may reference the github names? I'd be on board with that. )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's only used by the matching request source as of now so
Core Docs Errors[!] Failed Errors
Warnings
Generated by 🚫 danger |
On the topic of the gitlab gem I've reached out to Narkos over email. He is the registered owner of the gem on https://rubygems.org. Issuing a 3.7.0 of gitlab is currently the largest blocker for this to be merged |
a51e545
to
9c3ddc0
Compare
@k0nserv any reply from Narkos? |
No word from Narkos yet. You wanna try the Rubygems route? |
Might be possible to convince them to give @asedge push access |
i would be scared if it would work! how about forking it to |
I think it's better we see if we can get either the attention of asedge, or someone who works at GitLab, it's a pretty clear-cut choice to say that they should have access in the absence of Narkos. |
I'm undecided as to whether we should try to get control of the gem or create a new one, I've asked fellow GitLabbers for their input. It'd also be good to have your thoughts, @asedge, seeing as you're the primary maintainer currently. |
c4129a6
to
312e59b
Compare
@orta Do you wanna exclude GitLab CI on account of it not being supported as of now? |
You mean merge this, but not let the code-paths be accessible? That can work for me |
Either that or not merge it at all. Until they support some way of exposing the MR id in GitLab CI Danger won't work at all, even after that they need to support triggering builds on comments/edits for full support |
All though if we include it as it stands right now people are free to build small servers that interact with GitLab's build hooks to expose the correct env variables |
I'd merge it and allow people to build their own workflows, even if GitLab CI doesn't work now, people can still use Jenkins or any other form of CI to trigger the build. |
The question is not about other CI tools though, it's specifically about |
Aye, I'm on the let's merge it, but comment out the |
I also believe that assuming that Danger only works on PRs is wrong as in fact danger could work on any given changeset. We need to start thinking about removing that tight coupling somehow and maybe even move out PR updaters to a plugin. |
Could, yes, I guess I can see some usage as a pre-linter, but it might not be worth the overhead for support. |
1238b3d
to
634a525
Compare
👍 looking forward to adding this to all my tests now 😃 |
Don't do this ATM, I've already removed it in one PR - #418 - I'm not sure what its replacement should look like yet |
Hey all, we've gotten the current maintainer of the GitLab gem able to ship new releases! 3.7.0 is now out! https://rubygems.org/gems/gitlab |
🎉 |
336a98e
to
9563012
Compare
I believe this should be ready for review now. I haven't written any code to update the status of the merge request yet, but I'd prefer to merge first and then add this |
The other thing that remains is updating CI sources that support GitLab. I don't believe this to be a blocker for the merge either |
Instead of relying on width="100%" which is specific to the github markdown to find danger tables use `data-danger-table="true"`
# The new method uses a more robust data-danger-table | ||
# tag instead. | ||
match = GITHUB_OLD_REGEX.match(table) | ||
return match if match |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
OK, so yeah, this looks good, I have only minor nitpicks about the tests - but that's not a blocker for me at all. I'm going to merge this into another branch on danger ( I want to be able to deploy master whenever ) so I can get this rebased, documented and green. A new PR will be coming in soon, once I get back to my main computer. This has been a bunch of work from a quite a few developers, thanks to all of you. 💯 |
nice thx guys!!! |
Opening this PR for tracking purposes and comments from everyone else. There's still some work that needs to be finished up
gitlab
gem issuedcc @orta, @connorshea, @hjanuschka, @jk