Merge branch 'master' into 25990-web-terminal-improvements
* master: (66 commits) Allows to cancel a Created job Enable frozen string in rest of app/models/**/*.rb docs: removed duplicate `git_ssh_url` field from build event example Bump pry to 0.11.3; pry-byebug to 3.4.3 Update GitLab Shell to v8.1.1 to fix regressions Rails5 fix specs duplicate key value violates unique constraint 'index_gpg_signatures_on_commit_sha' Add mock data for spam logs Disable danger in preparation branches [ci-skip] add changelog Add default avatar to group Fix label item height when no desc Fix docs linting Fix missed port Consistent padding but correct label-actions-list positioning and label-links margin Phase 2: #47282 Improving Contributor On-Boarding Documentation Fix label item height when no desc Resolve "docs update api for usage with an array of hashes" removed un-used commits for currentProject & currentBranchId Allow the Web IDE to open empty merge requests Add rubocop check for add_reference to require index. ...
This commit is contained in:
Filipa Lacerda
commit
ab44f53199
|
|
@ -453,6 +453,7 @@ danger-review:
|
|||
- master
|
||||
variables:
|
||||
- $CI_COMMIT_REF_NAME =~ /^ce-to-ee-.*/
|
||||
- $CI_COMMIT_REF_NAME =~ /.*-stable(-ee)?-prepare-.*/
|
||||
script:
|
||||
- git version
|
||||
- danger --fail-on-errors=true
|
||||
|
|
|
|||
805
CONTRIBUTING.md
805
CONTRIBUTING.md
|
|
@ -21,41 +21,47 @@ _This notice should stay as the first item in the CONTRIBUTING.md file._
|
|||
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
||||
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
|
||||
|
||||
- [Contributing Documentation has been moved](#contributing-documentation-has-been-moved)
|
||||
- [Contribute to GitLab](#contribute-to-gitlab)
|
||||
- [Security vulnerability disclosure](#security-vulnerability-disclosure)
|
||||
- [Code of conduct](#code-of-conduct)
|
||||
- [Closing policy for issues and merge requests](#closing-policy-for-issues-and-merge-requests)
|
||||
- [Helping others](#helping-others)
|
||||
- [I want to contribute!](#i-want-to-contribute)
|
||||
- [Contribution Flow](#contribution-flow)
|
||||
- [Workflow labels](#workflow-labels)
|
||||
- [Type labels](#type-labels)
|
||||
- [Subject labels](#subject-labels)
|
||||
- [Team labels](#team-labels)
|
||||
- [Release Scoping labels](#release-scoping-labels)
|
||||
- [Bug Priority labels](#bug-priority-labels)
|
||||
- [Bug Severity labels](#bug-severity-labels)
|
||||
- [Severity impact guidance](#severity-impact-guidance)
|
||||
- [Label for community contributors](#label-for-community-contributors)
|
||||
- [Implement design & UI elements](#implement-design-ui-elements)
|
||||
- [Type labels](#type-labels)
|
||||
- [Subject labels](#subject-labels)
|
||||
- [Team labels](#team-labels)
|
||||
- [Release Scoping labels](#release-scoping-labels)
|
||||
- [Priority labels](#priority-labels)
|
||||
- [Severity labels](#severity-labels)
|
||||
- [Severity impact guidance](#severity-impact-guidance)
|
||||
- [Label for community contributors](#label-for-community-contributors)
|
||||
- [Implement design & UI elements](#implement-design--ui-elements)
|
||||
- [Issue tracker](#issue-tracker)
|
||||
- [Issue triaging](#issue-triaging)
|
||||
- [Feature proposals](#feature-proposals)
|
||||
- [Issue tracker guidelines](#issue-tracker-guidelines)
|
||||
- [Issue weight](#issue-weight)
|
||||
- [Regression issues](#regression-issues)
|
||||
- [Technical and UX debt](#technical-and-ux-debt)
|
||||
- [Stewardship](#stewardship)
|
||||
- [Issue triaging](#issue-triaging)
|
||||
- [Feature proposals](#feature-proposals)
|
||||
- [Issue tracker guidelines](#issue-tracker-guidelines)
|
||||
- [Issue weight](#issue-weight)
|
||||
- [Regression issues](#regression-issues)
|
||||
- [Technical and UX debt](#technical-and-ux-debt)
|
||||
- [Stewardship](#stewardship)
|
||||
- [Merge requests](#merge-requests)
|
||||
- [Merge request guidelines](#merge-request-guidelines)
|
||||
- [Contribution acceptance criteria](#contribution-acceptance-criteria)
|
||||
- [Merge request guidelines](#merge-request-guidelines)
|
||||
- [Contribution acceptance criteria](#contribution-acceptance-criteria)
|
||||
- [Definition of done](#definition-of-done)
|
||||
- [Style guides](#style-guides)
|
||||
- [Code of conduct](#code-of-conduct)
|
||||
- [Contribution Flow](#contribution-flow)
|
||||
|
||||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||||
|
||||
---
|
||||
|
||||
## Contributing Documentation has been moved
|
||||
|
||||
As of July 2018, all the documentation for contributing to the GitLab project has been moved to a new location.
|
||||
[view the new documentation](doc/development/contributing/index.md) to find the latest information.
|
||||
|
||||
## Contribute to GitLab
|
||||
|
||||
For a first-time step-by-step guide to the contribution process, see
|
||||
|
|
@ -84,6 +90,36 @@ Please report suspected security vulnerabilities in private to
|
|||
Please do **NOT** create publicly viewable issues for suspected security
|
||||
vulnerabilities.
|
||||
|
||||
## Code of conduct
|
||||
|
||||
As contributors and maintainers of this project, we pledge to respect all
|
||||
people who contribute through reporting issues, posting feature requests,
|
||||
updating documentation, submitting pull requests or patches, and other
|
||||
activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, or religion.
|
||||
|
||||
Examples of unacceptable behavior by participants include the use of sexual
|
||||
language or imagery, derogatory comments or personal attacks, trolling, public
|
||||
or private harassment, insults, or other unprofessional conduct.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct. Project maintainers who do not
|
||||
follow the Code of Conduct may be removed from the project team.
|
||||
|
||||
This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior can be
|
||||
reported by emailing `contact@gitlab.com`.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][contributor-covenant], version 1.1.0,
|
||||
available at [http://contributor-covenant.org/version/1/1/0/](http://contributor-covenant.org/version/1/1/0/).
|
||||
|
||||
## Closing policy for issues and merge requests
|
||||
|
||||
GitLab is a popular open source project and the capacity to deal with issues
|
||||
|
|
@ -123,623 +159,6 @@ learn how to communicate with GitLab. If you're looking for a Gitter or Slack ch
|
|||
please consider we favor
|
||||
[asynchronous communication](https://about.gitlab.com/handbook/communication/#internal-communication) over real time communication. Thanks for your contribution!
|
||||
|
||||
## Workflow labels
|
||||
|
||||
To allow for asynchronous issue handling, we use [milestones][milestones-page]
|
||||
and [labels][labels-page]. Leads and product managers handle most of the
|
||||
scheduling into milestones. Labelling is a task for everyone.
|
||||
|
||||
Most issues will have labels for at least one of the following:
|
||||
|
||||
- Type: ~"feature proposal", ~bug, ~customer, etc.
|
||||
- Subject: ~wiki, ~"container registry", ~ldap, ~api, ~frontend, etc.
|
||||
- Team: ~"CI/CD", ~Plan, ~Manage, ~Quality, etc.
|
||||
- Release Scoping: ~Deliverable, ~Stretch, ~"Next Patch Release"
|
||||
- Priority: ~P1, ~P2, ~P3, ~P4
|
||||
- Severity: ~S1, ~S2, ~S3, ~S4
|
||||
|
||||
All labels, their meaning and priority are defined on the
|
||||
[labels page][labels-page].
|
||||
|
||||
If you come across an issue that has none of these, and you're allowed to set
|
||||
labels, you can _always_ add the team and type, and often also the subject.
|
||||
|
||||
[milestones-page]: https://gitlab.com/gitlab-org/gitlab-ce/milestones
|
||||
[labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels
|
||||
|
||||
### Type labels
|
||||
|
||||
Type labels are very important. They define what kind of issue this is. Every
|
||||
issue should have one or more.
|
||||
|
||||
Examples of type labels are ~"feature proposal", ~bug, ~customer, ~security,
|
||||
and ~"direction".
|
||||
|
||||
A number of type labels have a priority assigned to them, which automatically
|
||||
makes them float to the top, depending on their importance.
|
||||
|
||||
Type labels are always lowercase, and can have any color, besides blue (which is
|
||||
already reserved for subject labels).
|
||||
|
||||
The descriptions on the [labels page][labels-page] explain what falls under each type label.
|
||||
|
||||
### Subject labels
|
||||
|
||||
Subject labels are labels that define what area or feature of GitLab this issue
|
||||
hits. They are not always necessary, but very convenient.
|
||||
|
||||
Examples of subject labels are ~wiki, ~ldap, ~api,
|
||||
~issues, ~"merge requests", ~labels, and ~"container registry".
|
||||
|
||||
If you are an expert in a particular area, it makes it easier to find issues to
|
||||
work on. You can also subscribe to those labels to receive an email each time an
|
||||
issue is labeled with a subject label corresponding to your expertise.
|
||||
|
||||
Subject labels are always all-lowercase.
|
||||
|
||||
### Team labels
|
||||
|
||||
Team labels specify what team is responsible for this issue.
|
||||
Assigning a team label makes sure issues get the attention of the appropriate
|
||||
people.
|
||||
|
||||
The current team labels are:
|
||||
|
||||
- ~Configuration
|
||||
- ~"CI/CD"
|
||||
- ~Create
|
||||
- ~Distribution
|
||||
- ~Documentation
|
||||
- ~Geo
|
||||
- ~Gitaly
|
||||
- ~Manage
|
||||
- ~Monitoring
|
||||
- ~Plan
|
||||
- ~Quality
|
||||
- ~Release
|
||||
- ~Secure
|
||||
- ~UX
|
||||
|
||||
The descriptions on the [labels page][labels-page] explain what falls under the
|
||||
responsibility of each team.
|
||||
|
||||
Within those team labels, we also have the ~backend and ~frontend labels to
|
||||
indicate if an issue needs backend work, frontend work, or both.
|
||||
|
||||
Team labels are always capitalized so that they show up as the first label for
|
||||
any issue.
|
||||
|
||||
### Release Scoping labels
|
||||
|
||||
Release Scoping labels help us clearly communicate expectations of the work for the
|
||||
release. There are three levels of Release Scoping labels:
|
||||
|
||||
- ~Deliverable: Issues that are expected to be delivered in the current
|
||||
milestone.
|
||||
- ~Stretch: Issues that are a stretch goal for delivering in the current
|
||||
milestone. If these issues are not done in the current release, they will
|
||||
strongly be considered for the next release.
|
||||
- ~"Next Patch Release": Issues to put in the next patch release. Work on these
|
||||
first, and add the "Pick Into X" label to the merge request, along with the
|
||||
appropriate milestone.
|
||||
|
||||
Each issue scheduled for the current milestone should be labeled ~Deliverable
|
||||
or ~"Stretch". Any open issue for a previous milestone should be labeled
|
||||
~"Next Patch Release", or otherwise rescheduled to a different milestone.
|
||||
|
||||
### Priority labels
|
||||
|
||||
Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be.
|
||||
If there are multiple defects, the priority decides which defect has to be fixed immediately versus later.
|
||||
This label documents the planned timeline & urgency which is used to measure against our actual SLA on delivering ~bug fixes.
|
||||
|
||||
| Label | Meaning | Estimate time to fix |
|
||||
|-------|-----------------|------------------------------------------------------------------|
|
||||
| ~P1 | Urgent Priority | The current release + potentially immediate hotfix to GitLab.com |
|
||||
| ~P2 | High Priority | The next release |
|
||||
| ~P3 | Medium Priority | Within the next 3 releases (approx one quarter) |
|
||||
| ~P4 | Low Priority | Anything outside the next 3 releases (approx beyond one quarter) |
|
||||
|
||||
### Severity labels
|
||||
|
||||
Severity labels help us clearly communicate the impact of a ~bug on users.
|
||||
|
||||
| Label | Meaning | Impact on Functionality | Example |
|
||||
|-------|-------------------|-------------------------------------------------------|---------|
|
||||
| ~S1 | Blocker | Outage, broken feature with no workaround | Unable to create an issue. Data corruption/loss. Security breach. |
|
||||
| ~S2 | Critical Severity | Broken Feature, workaround too complex & unacceptable | Can push commits, but only via the command line. |
|
||||
| ~S3 | Major Severity | Broken Feature, workaround acceptable | Can create merge requests only from the Merge Requests page, not through the Issue. |
|
||||
| ~S4 | Low Severity | Functionality inconvenience or cosmetic issue | Label colors are incorrect / not being displayed. |
|
||||
|
||||
#### Severity impact guidance
|
||||
|
||||
Severity levels can be applied further depending on the facet of the impact; e.g. Affected customers, GitLab.com availability, performance and etc. The below is a guideline.
|
||||
|
||||
| Severity | Affected Customers/Users | GitLab.com Availability | Performance Degradation |
|
||||
|----------|---------------------------------------------------------------------|----------------------------------------------------|------------------------------|
|
||||
| ~S1 | >50% users affected (possible company extinction level event) | Significant impact on all of GitLab.com | |
|
||||
| ~S2 | Many users or multiple paid customers affected (but not apocalyptic)| Significant impact on large portions of GitLab.com | Degradation is guaranteed to occur in the near future |
|
||||
| ~S3 | A few users or a single paid customer affected | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future |
|
||||
| ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on on GitLab.com | Degradation _may_ occur but it's not likely |
|
||||
|
||||
### Label for community contributors
|
||||
|
||||
Issues that are beneficial to our users, 'nice to haves', that we currently do
|
||||
not have the capacity for or want to give the priority to, are labeled as
|
||||
~"Accepting Merge Requests", so the community can make a contribution.
|
||||
|
||||
Community contributors can submit merge requests for any issue they want, but
|
||||
the ~"Accepting Merge Requests" label has a special meaning. It points to
|
||||
changes that:
|
||||
|
||||
1. We already agreed on,
|
||||
1. Are well-defined,
|
||||
1. Are likely to get accepted by a maintainer.
|
||||
|
||||
We want to avoid a situation when a contributor picks an
|
||||
~"Accepting Merge Requests" issue and then their merge request gets closed,
|
||||
because we realize that it does not fit our vision, or we want to solve it in a
|
||||
different way.
|
||||
|
||||
We add the ~"Accepting Merge Requests" label to:
|
||||
|
||||
- Low priority ~bug issues (i.e. we do not add it to the bugs that we want to
|
||||
solve in the ~"Next Patch Release")
|
||||
- Small ~"feature proposal"
|
||||
- Small ~"technical debt" issues
|
||||
|
||||
After adding the ~"Accepting Merge Requests" label, we try to estimate the
|
||||
[weight](#issue-weight) of the issue. We use issue weight to let contributors
|
||||
know how difficult the issue is. Additionally:
|
||||
|
||||
- We advertise ["Accepting Merge Requests" issues with weight < 5][up-for-grabs]
|
||||
as suitable for people that have never contributed to GitLab before on the
|
||||
[Up For Grabs campaign](http://up-for-grabs.net)
|
||||
- We encourage people that have never contributed to any open source project to
|
||||
look for ["Accepting Merge Requests" issues with a weight of 1][firt-timers]
|
||||
|
||||
If you've decided that you would like to work on an issue, please @-mention
|
||||
the [appropriate product manager](https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what)
|
||||
as soon as possible. The product manager will then pull in appropriate GitLab team
|
||||
members to further discuss scope, design, and technical considerations. This will
|
||||
ensure that that your contribution is aligned with the GitLab product and minimize
|
||||
any rework and delay in getting it merged into master.
|
||||
|
||||
GitLab team members who apply the ~"Accepting Merge Requests" label to an issue
|
||||
should update the issue description with a responsible product manager, inviting
|
||||
any potential community contributor to @-mention per above.
|
||||
|
||||
[up-for-grabs]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name=Accepting+Merge+Requests&scope=all&sort=weight_asc&state=opened
|
||||
[firt-timers]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=Accepting+Merge+Requests&scope=all&sort=upvotes_desc&state=opened&weight=1
|
||||
|
||||
## Implement design & UI elements
|
||||
|
||||
For guidance on UX implementation at GitLab, please refer to our [Design System](https://design.gitlab.com/).
|
||||
|
||||
The UX team uses labels to manage their workflow.
|
||||
|
||||
The ~"UX" label on an issue is a signal to the UX team that it will need UX attention.
|
||||
To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux) of the handbook.
|
||||
|
||||
Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.
|
||||
|
||||
The UX team has a special type label called ~"design artifact". This label indicates that the final output
|
||||
for an issue is a UX solution/design. The solution will be developed by frontend and/or backend in a subsequent milestone.
|
||||
Any issue labeled ~"design artifact" should not also be labeled ~"frontend" or ~"backend" since no development is
|
||||
needed until the solution has been decided.
|
||||
|
||||
~"design artifact" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.
|
||||
|
||||
To prevent the misunderstanding that a feature will be be delivered in the
|
||||
assigned milestone, when only UX design is planned for that milestone, the
|
||||
Product Manager should create a separate issue for the ~"design artifact",
|
||||
assign the ~UX, ~"design artifact" and ~"Deliverable" labels, add a milestone
|
||||
and use a title that makes it clear that the scheduled issue is design only
|
||||
(e.g. `Design exploration for XYZ`).
|
||||
|
||||
When the ~"design artifact" issue has been completed, the UXer removes the ~UX
|
||||
label, adds the ~"UX ready" label and closes the issue. This indicates the
|
||||
design artifact is complete. The UXer will also copy the designs to related
|
||||
issues for implementation in an upcoming milestone.
|
||||
|
||||
## Issue tracker
|
||||
|
||||
To get support for your particular problem please use the
|
||||
[getting help channels](https://about.gitlab.com/getting-help/).
|
||||
|
||||
The [GitLab CE issue tracker on GitLab.com][ce-tracker] is for bugs concerning
|
||||
the latest GitLab release and [feature proposals](#feature-proposals).
|
||||
|
||||
When submitting an issue please conform to the issue submission guidelines
|
||||
listed below. Not all issues will be addressed and your issue is more likely to
|
||||
be addressed if you submit a merge request which partially or fully solves
|
||||
the issue.
|
||||
|
||||
If you're unsure where to post, post to the [mailing list][google-group] or
|
||||
[Stack Overflow][stackoverflow] first. There are a lot of helpful GitLab users
|
||||
there who may be able to help you quickly. If your particular issue turns out
|
||||
to be a bug, it will find its way from there.
|
||||
|
||||
If it happens that you know the solution to an existing bug, please first
|
||||
open the issue in order to keep track of it and then open the relevant merge
|
||||
request that potentially fixes it.
|
||||
|
||||
### Issue triaging
|
||||
|
||||
Our issue triage policies are [described in our handbook]. You are very welcome
|
||||
to help the GitLab team triage issues. We also organize [issue bash events] once
|
||||
every quarter.
|
||||
|
||||
The most important thing is making sure valid issues receive feedback from the
|
||||
development team. Therefore the priority is mentioning developers that can help
|
||||
on those issues. Please select someone with relevant experience from the
|
||||
[GitLab team][team]. If there is nobody mentioned with that expertise look in
|
||||
the commit history for the affected files to find someone.
|
||||
|
||||
We also use [GitLab Triage] to automate some triaging policies. This is
|
||||
currently setup as a [scheduled pipeline] running on [quality/triage-ops]
|
||||
project.
|
||||
|
||||
[described in our handbook]: https://about.gitlab.com/handbook/engineering/issue-triage/
|
||||
[issue bash events]: https://gitlab.com/gitlab-org/gitlab-ce/issues/17815
|
||||
[GitLab Triage]: https://gitlab.com/gitlab-org/gitlab-triage
|
||||
[scheduled pipeline]: https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit
|
||||
[quality/triage-ops]: https://gitlab.com/gitlab-org/quality/triage-ops
|
||||
|
||||
### Feature proposals
|
||||
|
||||
To create a feature proposal for CE, open an issue on the
|
||||
[issue tracker of CE][ce-tracker].
|
||||
|
||||
For feature proposals for EE, open an issue on the
|
||||
[issue tracker of EE][ee-tracker].
|
||||
|
||||
In order to help track the feature proposals, we have created a
|
||||
[`feature proposal`][fpl] label. For the time being, users that are not members
|
||||
of the project cannot add labels. You can instead ask one of the [core team]
|
||||
members to add the label ~"feature proposal" to the issue or add the following
|
||||
code snippet right after your description in a new line: `~"feature proposal"`.
|
||||
|
||||
Please keep feature proposals as small and simple as possible, complex ones
|
||||
might be edited to make them small and simple.
|
||||
|
||||
Please submit Feature Proposals using the ['Feature Proposal' issue template](.gitlab/issue_templates/Feature Proposal.md) provided on the issue tracker.
|
||||
|
||||
For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should
|
||||
be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may
|
||||
need to ask one of the [core team] members to add the label, if you do not have permissions to do it by yourself.
|
||||
|
||||
If you want to create something yourself, consider opening an issue first to
|
||||
discuss whether it is interesting to include this in GitLab.
|
||||
|
||||
### Issue tracker guidelines
|
||||
|
||||
**[Search the issue tracker][ce-tracker]** for similar entries before
|
||||
submitting your own, there's a good chance somebody else had the same issue or
|
||||
feature proposal. Show your support with an award emoji and/or join the
|
||||
discussion.
|
||||
|
||||
Please submit bugs using the ['Bug' issue template](.gitlab/issue_templates/Bug.md) provided on the issue tracker.
|
||||
The text in the parenthesis is there to help you with what to include. Omit it
|
||||
when submitting the actual issue. You can copy-paste it and then edit as you
|
||||
see fit.
|
||||
|
||||
### Issue weight
|
||||
|
||||
Issue weight allows us to get an idea of the amount of work required to solve
|
||||
one or multiple issues. This makes it possible to schedule work more accurately.
|
||||
|
||||
You are encouraged to set the weight of any issue. Following the guidelines
|
||||
below will make it easy to manage this, without unnecessary overhead.
|
||||
|
||||
1. Set weight for any issue at the earliest possible convenience
|
||||
1. If you don't agree with a set weight, discuss with other developers until
|
||||
consensus is reached about the weight
|
||||
1. Issue weights are an abstract measurement of complexity of the issue. Do not
|
||||
relate issue weight directly to time. This is called [anchoring](https://en.wikipedia.org/wiki/Anchoring)
|
||||
and something you want to avoid.
|
||||
1. Something that has a weight of 1 (or no weight) is really small and simple.
|
||||
Something that is 9 is rewriting a large fundamental part of GitLab,
|
||||
which might lead to many hard problems to solve. Changing some text in GitLab
|
||||
is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9.
|
||||
1. If something is very large, it should probably be split up in multiple
|
||||
issues or chunks. You can simply not set the weight of a parent issue and set
|
||||
weights to children issues.
|
||||
|
||||
### Regression issues
|
||||
|
||||
Every monthly release has a corresponding issue on the CE issue tracker to keep
|
||||
track of functionality broken by that release and any fixes that need to be
|
||||
included in a patch release (see [8.3 Regressions] as an example).
|
||||
|
||||
As outlined in the issue description, the intended workflow is to post one note
|
||||
with a reference to an issue describing the regression, and then to update that
|
||||
note with a reference to the merge request that fixes it as it becomes available.
|
||||
|
||||
If you're a contributor who doesn't have the required permissions to update
|
||||
other users' notes, please post a new note with a reference to both the issue
|
||||
and the merge request.
|
||||
|
||||
The release manager will [update the notes] in the regression issue as fixes are
|
||||
addressed.
|
||||
|
||||
[8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4127
|
||||
[update the notes]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue
|
||||
|
||||
### Technical and UX debt
|
||||
|
||||
In order to track things that can be improved in GitLab's codebase,
|
||||
we use the ~"technical debt" label in [GitLab's issue tracker][ce-tracker].
|
||||
For user experience improvements, we use the ~"UX debt" label.
|
||||
|
||||
These labels should be added to issues that describe things that can be improved,
|
||||
shortcuts that have been taken, features that need additional attention, and all
|
||||
other things that have been left behind due to high velocity of development.
|
||||
For example, code that needs refactoring should use the ~"technical debt" label,
|
||||
user experience refinements should use the ~"UX debt" label.
|
||||
|
||||
Everyone can create an issue, though you may need to ask for adding a specific
|
||||
label, if you do not have permissions to do it by yourself. Additional labels
|
||||
can be combined with these labels, to make it easier to schedule
|
||||
the improvements for a release.
|
||||
|
||||
Issues tagged with these labels have the same priority like issues
|
||||
that describe a new feature to be introduced in GitLab, and should be scheduled
|
||||
for a release by the appropriate person.
|
||||
|
||||
Make sure to mention the merge request that the ~"technical debt" issue or
|
||||
~"UX debt" issue is associated with in the description of the issue.
|
||||
|
||||
### Stewardship
|
||||
|
||||
For issues related to the open source stewardship of GitLab,
|
||||
there is the ~"stewardship" label.
|
||||
|
||||
This label is to be used for issues in which the stewardship of GitLab
|
||||
is a topic of discussion. For instance if GitLab Inc. is planning to add
|
||||
features from GitLab EE to GitLab CE, related issues would be labelled with
|
||||
~"stewardship".
|
||||
|
||||
A recent example of this was the issue for
|
||||
[bringing the time tracking API to GitLab CE][time-tracking-issue].
|
||||
|
||||
[time-tracking-issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/25517#note_20019084
|
||||
|
||||
## Merge requests
|
||||
|
||||
We welcome merge requests with fixes and improvements to GitLab code, tests,
|
||||
and/or documentation. The issues that are specifically suitable for
|
||||
community contributions are listed with the label
|
||||
[`Accepting Merge Requests` on our issue tracker for CE][accepting-mrs-ce]
|
||||
and [EE][accepting-mrs-ee], but you are free to contribute to any other issue
|
||||
you want.
|
||||
|
||||
Please note that if an issue is marked for the current milestone either before
|
||||
or while you are working on it, a team member may take over the merge request
|
||||
in order to ensure the work is finished before the release date.
|
||||
|
||||
If you want to add a new feature that is not labeled it is best to first create
|
||||
a feedback issue (if there isn't one already) and leave a comment asking for it
|
||||
to be marked as `Accepting Merge Requests`. Please include screenshots or
|
||||
wireframes if the feature will also change the UI.
|
||||
|
||||
Merge requests should be opened at [GitLab.com][gitlab-mr-tracker].
|
||||
|
||||
If you are new to GitLab development (or web development in general), see the
|
||||
[I want to contribute!](#i-want-to-contribute) section to get you started with
|
||||
some potentially easy issues.
|
||||
|
||||
To start with GitLab development download the [GitLab Development Kit][gdk] and
|
||||
see the [Development section](doc/development/README.md) for some guidelines.
|
||||
|
||||
### Merge request guidelines
|
||||
|
||||
If you can, please submit a merge request with the fix or improvements
|
||||
including tests. If you don't know how to fix the issue but can write a test
|
||||
that exposes the issue we will accept that as well. In general bug fixes that
|
||||
include a regression test are merged quickly while new features without proper
|
||||
tests are least likely to receive timely feedback. The workflow to make a merge
|
||||
request is as follows:
|
||||
|
||||
1. Fork the project into your personal space on GitLab.com
|
||||
1. Create a feature branch, branch away from `master`
|
||||
1. Write [tests](https://docs.gitlab.com/ee/development/rake_tasks.html#run-tests) and code
|
||||
1. [Generate a changelog entry with `bin/changelog`][changelog]
|
||||
1. If you are writing documentation, make sure to follow the
|
||||
[documentation guidelines][doc-guidelines]
|
||||
1. If you have multiple commits please combine them into a few logically
|
||||
organized commits by [squashing them][git-squash]
|
||||
1. Push the commit(s) to your fork
|
||||
1. Submit a merge request (MR) to the `master` branch
|
||||
1. Your merge request needs at least 1 approval but feel free to require more.
|
||||
For instance if you're touching backend and frontend code, it's a good idea
|
||||
to require 2 approvals: 1 from a backend maintainer and 1 from a frontend
|
||||
maintainer
|
||||
1. You don't have to select any approvers, but you can if you really want
|
||||
specific people to approve your merge request
|
||||
1. The MR title should describe the change you want to make
|
||||
1. The MR description should give a motive for your change and the method you
|
||||
used to achieve it.
|
||||
1. If you are contributing code, fill in the template already provided in the
|
||||
"Description" field.
|
||||
1. If you are contributing documentation, choose `Documentation` from the
|
||||
"Choose a template" menu and fill in the template.
|
||||
1. Mention the issue(s) your merge request solves, using the `Solves #XXX` or
|
||||
`Closes #XXX` syntax to auto-close the issue(s) once the merge request will
|
||||
be merged.
|
||||
1. If you're allowed to, set a relevant milestone and labels
|
||||
1. If the MR changes the UI it should include *Before* and *After* screenshots
|
||||
1. If the MR changes CSS classes please include the list of affected pages,
|
||||
`grep css-class ./app -R`
|
||||
1. Be prepared to answer questions and incorporate feedback even if requests
|
||||
for this arrive weeks or months after your MR submission
|
||||
1. If a discussion has been addressed, select the "Resolve discussion" button
|
||||
beneath it to mark it resolved.
|
||||
1. If your MR touches code that executes shell commands, reads or opens files or
|
||||
handles paths to files on disk, make sure it adheres to the
|
||||
[shell command guidelines](doc/development/shell_commands.md)
|
||||
1. If your code creates new files on disk please read the
|
||||
[shared files guidelines](doc/development/shared_files.md).
|
||||
1. When writing commit messages please follow
|
||||
[these](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
||||
[guidelines](http://chris.beams.io/posts/git-commit/).
|
||||
1. If your merge request adds one or more migrations, make sure to execute all
|
||||
migrations on a fresh database before the MR is reviewed. If the review leads
|
||||
to large changes in the MR, do this again once the review is complete.
|
||||
1. For more complex migrations, write tests.
|
||||
1. Merge requests **must** adhere to the [merge request performance
|
||||
guidelines](doc/development/merge_request_performance_guidelines.md).
|
||||
1. For tests that use Capybara or PhantomJS, see this [article on how
|
||||
to write reliable asynchronous tests](https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara).
|
||||
|
||||
Please keep the change in a single MR **as small as possible**. If you want to
|
||||
contribute a large feature think very hard what the minimum viable change is.
|
||||
Can you split the functionality? Can you only submit the backend/API code? Can
|
||||
you start with a very simple UI? Can you do part of the refactor? The increased
|
||||
reviewability of small MRs that leads to higher code quality is more important
|
||||
to us than having a minimal commit log. The smaller an MR is the more likely it
|
||||
is it will be merged (quickly). After that you can send more MRs to enhance it.
|
||||
The ['How to get faster PR reviews' document of Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/devel/faster_reviews.md) also has some great points regarding this.
|
||||
|
||||
For examples of feedback on merge requests please look at already
|
||||
[closed merge requests][closed-merge-requests]. If you would like quick feedback
|
||||
on your merge request feel free to mention someone from the [core team] or one
|
||||
of the [Merge request coaches][team].
|
||||
Please ensure that your merge request meets the contribution acceptance criteria.
|
||||
|
||||
When having your code reviewed and when reviewing merge requests please take the
|
||||
[code review guidelines](doc/development/code_review.md) into account.
|
||||
|
||||
### Contribution acceptance criteria
|
||||
|
||||
1. The change is as small as possible
|
||||
1. Include proper tests and make all tests pass (unless it contains a test
|
||||
exposing a bug in existing code). Every new class should have corresponding
|
||||
unit tests, even if the class is exercised at a higher level, such as a feature test.
|
||||
1. If you suspect a failing CI build is unrelated to your contribution, you may
|
||||
try and restart the failing CI job or ask a developer to fix the
|
||||
aforementioned failing test
|
||||
1. Your MR initially contains a single commit (please use `git rebase -i` to
|
||||
squash commits)
|
||||
1. Your changes can merge without problems (if not please rebase if you're the
|
||||
only one working on your feature branch, otherwise, merge `master`)
|
||||
1. Does not break any existing functionality
|
||||
1. Fixes one specific issue or implements one specific feature (do not combine
|
||||
things, send separate merge requests if needed)
|
||||
1. Migrations should do only one thing (e.g., either create a table, move data
|
||||
to a new table or remove an old table) to aid retrying on failure
|
||||
1. Keeps the GitLab code base clean and well structured
|
||||
1. Contains functionality we think other users will benefit from too
|
||||
1. Doesn't add configuration options or settings options since they complicate
|
||||
making and testing future changes
|
||||
1. Changes do not adversely degrade performance.
|
||||
- Avoid repeated polling of endpoints that require a significant amount of overhead
|
||||
- Check for N+1 queries via the SQL log or [`QueryRecorder`](https://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
|
||||
- Avoid repeated access of filesystem
|
||||
1. If you need polling to support real-time features, please use
|
||||
[polling with ETag caching][polling-etag].
|
||||
1. Changes after submitting the merge request should be in separate commits
|
||||
(no squashing).
|
||||
1. It conforms to the [style guides](#style-guides) and the following:
|
||||
- If your change touches a line that does not follow the style, modify the
|
||||
entire line to follow it. This prevents linting tools from generating warnings.
|
||||
- Don't touch neighbouring lines. As an exception, automatic mass
|
||||
refactoring modifications may leave style non-compliant.
|
||||
1. If the merge request adds any new libraries (gems, JavaScript libraries,
|
||||
etc.), they should conform to our [Licensing guidelines][license-finder-doc].
|
||||
See the instructions in that document for help if your MR fails the
|
||||
"license-finder" test with a "Dependencies that need approval" error.
|
||||
1. The merge request meets the [definition of done](#definition-of-done).
|
||||
|
||||
## Definition of done
|
||||
|
||||
If you contribute to GitLab please know that changes involve more than just
|
||||
code. We have the following [definition of done][definition-of-done]. Please ensure you support
|
||||
the feature you contribute through all of these steps.
|
||||
|
||||
1. Description explaining the relevancy (see following item)
|
||||
1. Working and clean code that is commented where needed
|
||||
1. [Unit, integration, and system tests][testing] that pass on the CI server
|
||||
1. Performance/scalability implications have been considered, addressed, and tested
|
||||
1. [Documented][doc-guidelines] in the `/doc` directory
|
||||
1. [Changelog entry added][changelog], if necessary
|
||||
1. Reviewed and any concerns are addressed
|
||||
1. Merged by a project maintainer
|
||||
1. Added to the release blog article, if relevant
|
||||
1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/), if relevant
|
||||
1. Community questions answered
|
||||
1. Answers to questions radiated (in docs/wiki/support etc.)
|
||||
|
||||
If you add a dependency in GitLab (such as an operating system package) please
|
||||
consider updating the following and note the applicability of each in your
|
||||
merge request:
|
||||
|
||||
1. Note the addition in the release blog post (create one if it doesn't exist yet) https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/
|
||||
1. Upgrade guide, for example https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/7.5-to-7.6.md
|
||||
1. Upgrader https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/upgrader.md#2-run-gitlab-upgrade-tool
|
||||
1. Installation guide https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md#1-packages-dependencies
|
||||
1. GitLab Development Kit https://gitlab.com/gitlab-org/gitlab-development-kit
|
||||
1. Test suite https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/prepare_build.sh
|
||||
1. Omnibus package creator https://gitlab.com/gitlab-org/omnibus-gitlab
|
||||
|
||||
## Style guides
|
||||
|
||||
1. [Ruby](https://github.com/bbatsov/ruby-style-guide).
|
||||
Important sections include [Source Code Layout][rss-source] and
|
||||
[Naming][rss-naming]. Use:
|
||||
- multi-line method chaining style **Option A**: dot `.` on the second line
|
||||
- string literal quoting style **Option A**: single quoted by default
|
||||
1. [Rails](https://github.com/bbatsov/rails-style-guide)
|
||||
1. [Newlines styleguide][newlines-styleguide]
|
||||
1. [Testing][testing]
|
||||
1. [JavaScript styleguide][js-styleguide]
|
||||
1. [SCSS styleguide][scss-styleguide]
|
||||
1. [Shell commands](doc/development/shell_commands.md) created by GitLab
|
||||
contributors to enhance security
|
||||
1. [Database Migrations](doc/development/migration_style_guide.md)
|
||||
1. [Markdown](http://www.cirosantilli.com/markdown-styleguide)
|
||||
1. [Documentation styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide.html)
|
||||
1. Interface text should be written subjectively instead of objectively. It
|
||||
should be the GitLab core team addressing a person. It should be written in
|
||||
present time and never use past tense (has been/was). For example instead
|
||||
of _prohibited this user from being saved due to the following errors:_ the
|
||||
text should be _sorry, we could not create your account because:_
|
||||
1. Code should be written in [US English][us-english]
|
||||
|
||||
This is also the style used by linting tools such as
|
||||
[RuboCop](https://github.com/bbatsov/rubocop),
|
||||
[PullReview](https://www.pullreview.com/) and [Hound CI](https://houndci.com).
|
||||
|
||||
## Code of conduct
|
||||
|
||||
As contributors and maintainers of this project, we pledge to respect all
|
||||
people who contribute through reporting issues, posting feature requests,
|
||||
updating documentation, submitting pull requests or patches, and other
|
||||
activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free
|
||||
experience for everyone, regardless of level of experience, gender, gender
|
||||
identity and expression, sexual orientation, disability, personal appearance,
|
||||
body size, race, ethnicity, age, or religion.
|
||||
|
||||
Examples of unacceptable behavior by participants include the use of sexual
|
||||
language or imagery, derogatory comments or personal attacks, trolling, public
|
||||
or private harassment, insults, or other unprofessional conduct.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct. Project maintainers who do not
|
||||
follow the Code of Conduct may be removed from the project team.
|
||||
|
||||
This code of conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior can be
|
||||
reported by emailing `contact@gitlab.com`.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][contributor-covenant], version 1.1.0,
|
||||
available at [http://contributor-covenant.org/version/1/1/0/](http://contributor-covenant.org/version/1/1/0/).
|
||||
|
||||
## Contribution Flow
|
||||
|
||||
When contributing to GitLab, your merge request is subject to review by merge request maintainers of a particular specialty.
|
||||
|
|
@ -789,3 +208,115 @@ When your code contains more than 500 changes, any major breaking changes, or an
|
|||
[polling-etag]: https://docs.gitlab.com/ce/development/polling.html
|
||||
[testing]: doc/development/testing_guide/index.md
|
||||
[us-english]: https://en.wikipedia.org/wiki/American_English
|
||||
|
||||
|
||||
## Workflow labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Type labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Subject labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Team labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Release Scoping labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Priority labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Severity labels
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
#### Severity impact guidance
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Label for community contributors
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
## Implement design & UI elements
|
||||
|
||||
This [documentation](doc/development/contributing/design.md) has been moved.
|
||||
|
||||
|
||||
## Issue tracker
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
### Issue triaging
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Feature proposals
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
### Issue tracker guidelines
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Issue weight
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Regression issues
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Technical and UX debt
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Stewardship
|
||||
|
||||
This [documentation](doc/development/contributing/issue_workflow.md) has been moved.
|
||||
|
||||
|
||||
## Merge requests
|
||||
|
||||
This [documentation](doc/development/contributing/merge_request_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Merge request guidelines
|
||||
|
||||
This [documentation](doc/development/contributing/merge_request_workflow.md) has been moved.
|
||||
|
||||
|
||||
### Contribution acceptance criteria
|
||||
|
||||
This [documentation](doc/development/contributing/merge_request_workflow.md) has been moved.
|
||||
|
||||
|
||||
## Definition of done
|
||||
|
||||
This [documentation](doc/development/contributing/merge_request_workflow.md)) has been moved.
|
||||
|
||||
|
||||
## Style guides
|
||||
|
||||
This [documentation](doc/development/contributing/design.md) has been moved.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
8.1.0
|
||||
8.1.1
|
||||
|
|
|
|||
16
Gemfile.lock
16
Gemfile.lock
|
|
@ -123,7 +123,7 @@ GEM
|
|||
numerizer (~> 0.1.1)
|
||||
chunky_png (1.3.5)
|
||||
citrus (3.0.2)
|
||||
coderay (1.1.1)
|
||||
coderay (1.1.2)
|
||||
coercible (1.0.0)
|
||||
descendants_tracker (~> 0.0.1)
|
||||
commonmarker (0.17.8)
|
||||
|
|
@ -494,7 +494,7 @@ GEM
|
|||
memoist (0.16.0)
|
||||
memoizable (0.4.2)
|
||||
thread_safe (~> 0.3, >= 0.3.1)
|
||||
method_source (0.8.2)
|
||||
method_source (0.9.0)
|
||||
mime-types (3.1)
|
||||
mime-types-data (~> 3.2015)
|
||||
mime-types-data (3.2016.0521)
|
||||
|
|
@ -636,12 +636,11 @@ GEM
|
|||
unparser
|
||||
procto (0.0.3)
|
||||
prometheus-client-mmap (0.9.4)
|
||||
pry (0.10.4)
|
||||
pry (0.11.3)
|
||||
coderay (~> 1.1.0)
|
||||
method_source (~> 0.8.1)
|
||||
slop (~> 3.4)
|
||||
pry-byebug (3.4.2)
|
||||
byebug (~> 9.0)
|
||||
method_source (~> 0.9.0)
|
||||
pry-byebug (3.4.3)
|
||||
byebug (>= 9.0, < 9.1)
|
||||
pry (~> 0.10)
|
||||
pry-rails (0.3.5)
|
||||
pry (>= 0.9.10)
|
||||
|
|
@ -872,7 +871,6 @@ GEM
|
|||
simplecov-html (~> 0.10.0)
|
||||
simplecov-html (0.10.0)
|
||||
slack-notifier (1.5.1)
|
||||
slop (3.6.0)
|
||||
spring (2.0.1)
|
||||
activesupport (>= 4.2)
|
||||
spring-commands-rspec (1.0.4)
|
||||
|
|
@ -1207,4 +1205,4 @@ DEPENDENCIES
|
|||
wikicloth (= 0.8.1)
|
||||
|
||||
BUNDLED WITH
|
||||
1.16.2
|
||||
1.16.3
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ router.beforeEach((to, from, next) => {
|
|||
mergeRequestId: to.params.mrid,
|
||||
})
|
||||
.then(mr => {
|
||||
store.dispatch('updateActivityBarView', activityBarViews.review);
|
||||
store.dispatch('setCurrentBranchId', mr.source_branch);
|
||||
|
||||
store.dispatch('getBranchData', {
|
||||
projectId: fullProjectId,
|
||||
|
|
@ -144,6 +144,10 @@ router.beforeEach((to, from, next) => {
|
|||
}),
|
||||
)
|
||||
.then(mrChanges => {
|
||||
if (mrChanges.changes.length) {
|
||||
store.dispatch('updateActivityBarView', activityBarViews.review);
|
||||
}
|
||||
|
||||
mrChanges.changes.forEach((change, ind) => {
|
||||
const changeTreeEntry = store.state.entries[change.new_path];
|
||||
|
||||
|
|
|
|||
|
|
@ -54,9 +54,6 @@ export const setFileActive = ({ commit, state, getters, dispatch }, path) => {
|
|||
|
||||
commit(types.SET_FILE_ACTIVE, { path, active: true });
|
||||
dispatch('scrollToTab');
|
||||
|
||||
commit(types.SET_CURRENT_PROJECT, file.projectId);
|
||||
commit(types.SET_CURRENT_BRANCH, file.branchId);
|
||||
};
|
||||
|
||||
export const getFileData = ({ state, commit, dispatch }, { path, makeFileActive = true }) => {
|
||||
|
|
|
|||
|
|
@ -1,3 +1,9 @@
|
|||
import initForm from '../form';
|
||||
import MirrorRepos from './mirror_repos';
|
||||
|
||||
document.addEventListener('DOMContentLoaded', initForm);
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
initForm();
|
||||
|
||||
const mirrorReposContainer = document.querySelector('.js-mirror-settings');
|
||||
if (mirrorReposContainer) new MirrorRepos(mirrorReposContainer).init();
|
||||
});
|
||||
|
|
|
|||
|
|
@ -0,0 +1,94 @@
|
|||
import $ from 'jquery';
|
||||
import _ from 'underscore';
|
||||
import { __ } from '~/locale';
|
||||
import Flash from '~/flash';
|
||||
import axios from '~/lib/utils/axios_utils';
|
||||
|
||||
export default class MirrorRepos {
|
||||
constructor(container) {
|
||||
this.$container = $(container);
|
||||
this.$form = $('.js-mirror-form', this.$container);
|
||||
this.$urlInput = $('.js-mirror-url', this.$form);
|
||||
this.$protectedBranchesInput = $('.js-mirror-protected', this.$form);
|
||||
this.$table = $('.js-mirrors-table-body', this.$container);
|
||||
this.mirrorEndpoint = this.$form.data('projectMirrorEndpoint');
|
||||
}
|
||||
|
||||
init() {
|
||||
this.initMirrorPush();
|
||||
this.registerUpdateListeners();
|
||||
}
|
||||
|
||||
initMirrorPush() {
|
||||
this.$passwordGroup = $('.js-password-group', this.$container);
|
||||
this.$password = $('.js-password', this.$passwordGroup);
|
||||
this.$authMethod = $('.js-auth-method', this.$form);
|
||||
|
||||
this.$authMethod.on('change', () => this.togglePassword());
|
||||
this.$password.on('input.updateUrl', () => this.debouncedUpdateUrl());
|
||||
}
|
||||
|
||||
updateUrl() {
|
||||
let val = this.$urlInput.val();
|
||||
|
||||
if (this.$password) {
|
||||
const password = this.$password.val();
|
||||
if (password) val = val.replace('@', `:${password}@`);
|
||||
}
|
||||
|
||||
$('.js-mirror-url-hidden', this.$form).val(val);
|
||||
}
|
||||
|
||||
updateProtectedBranches() {
|
||||
const val = this.$protectedBranchesInput.get(0).checked
|
||||
? this.$protectedBranchesInput.val()
|
||||
: '0';
|
||||
$('.js-mirror-protected-hidden', this.$form).val(val);
|
||||
}
|
||||
|
||||
registerUpdateListeners() {
|
||||
this.debouncedUpdateUrl = _.debounce(() => this.updateUrl(), 200);
|
||||
this.$urlInput.on('input', () => this.debouncedUpdateUrl());
|
||||
this.$protectedBranchesInput.on('change', () => this.updateProtectedBranches());
|
||||
this.$table.on('click', '.js-delete-mirror', event => this.deleteMirror(event));
|
||||
}
|
||||
|
||||
togglePassword() {
|
||||
const isPassword = this.$authMethod.val() === 'password';
|
||||
|
||||
if (!isPassword) {
|
||||
this.$password.val('');
|
||||
this.updateUrl();
|
||||
}
|
||||
this.$passwordGroup.collapse(isPassword ? 'show' : 'hide');
|
||||
}
|
||||
|
||||
deleteMirror(event, existingPayload) {
|
||||
const $target = $(event.currentTarget);
|
||||
let payload = existingPayload;
|
||||
|
||||
if (!payload) {
|
||||
payload = {
|
||||
project: {
|
||||
remote_mirrors_attributes: {
|
||||
id: $target.data('mirrorId'),
|
||||
enabled: 0,
|
||||
},
|
||||
},
|
||||
};
|
||||
}
|
||||
|
||||
return axios
|
||||
.put(this.mirrorEndpoint, payload)
|
||||
.then(() => this.removeRow($target))
|
||||
.catch(() => Flash(__('Failed to remove mirror.')));
|
||||
}
|
||||
|
||||
/* eslint-disable class-methods-use-this */
|
||||
removeRow($target) {
|
||||
const row = $target.closest('tr');
|
||||
$('.js-delete-mirror', row).tooltip('hide');
|
||||
row.remove();
|
||||
}
|
||||
/* eslint-enable class-methods-use-this */
|
||||
}
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
<script>
|
||||
import { mapActions, mapGetters, mapState } from 'vuex';
|
||||
import { s__ } from '~/locale';
|
||||
import { componentNames } from '~/vue_shared/components/reports/issue_body';
|
||||
import ReportSection from '~/vue_shared/components/reports/report_section.vue';
|
||||
import SummaryRow from '~/vue_shared/components/reports/summary_row.vue';
|
||||
import IssuesList from '~/vue_shared/components/reports/issues_list.vue';
|
||||
import { componentNames } from './issue_body';
|
||||
import ReportSection from './report_section.vue';
|
||||
import SummaryRow from './summary_row.vue';
|
||||
import IssuesList from './issues_list.vue';
|
||||
import Modal from './modal.vue';
|
||||
import createStore from '../store';
|
||||
import { summaryTextBuilder, reportTextBuilder, statusIcon } from '../store/utils';
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
import TestIssueBody from '~/reports/components/test_issue_body.vue';
|
||||
import TestIssueBody from './test_issue_body.vue';
|
||||
|
||||
export const components = {
|
||||
TestIssueBody,
|
||||
|
|
@ -1,11 +1,10 @@
|
|||
<script>
|
||||
import Icon from '~/vue_shared/components/icon.vue';
|
||||
|
||||
import {
|
||||
STATUS_FAILED,
|
||||
STATUS_NEUTRAL,
|
||||
STATUS_SUCCESS,
|
||||
} from '~/vue_shared/components/reports/constants';
|
||||
} from '../constants';
|
||||
|
||||
export default {
|
||||
name: 'IssueStatusIcon',
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
<script>
|
||||
import IssuesBlock from '~/vue_shared/components/reports/report_issues.vue';
|
||||
import IssuesBlock from './report_issues.vue';
|
||||
import {
|
||||
STATUS_SUCCESS,
|
||||
STATUS_FAILED,
|
||||
STATUS_NEUTRAL,
|
||||
} from '~/vue_shared/components/reports/constants';
|
||||
} from '../constants';
|
||||
|
||||
/**
|
||||
* Renders block of issues
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
<script>
|
||||
import IssueStatusIcon from '~/vue_shared/components/reports/issue_status_icon.vue';
|
||||
import { components, componentNames } from '~/vue_shared/components/reports/issue_body';
|
||||
import IssueStatusIcon from './issue_status_icon.vue';
|
||||
import { components, componentNames } from './issue_body';
|
||||
|
||||
export default {
|
||||
name: 'ReportIssues',
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
<script>
|
||||
import { __ } from '~/locale';
|
||||
import StatusIcon from '~/vue_merge_request_widget/components/mr_widget_status_icon.vue';
|
||||
import Popover from '~/vue_shared/components/help_popover.vue';
|
||||
import IssuesList from './issues_list.vue';
|
||||
import Popover from '../help_popover.vue';
|
||||
|
||||
const LOADING = 'LOADING';
|
||||
const ERROR = 'ERROR';
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
<script>
|
||||
import CiIcon from '~/vue_shared/components/ci_icon.vue';
|
||||
import LoadingIcon from '~/vue_shared/components/loading_icon.vue';
|
||||
import Popover from '../help_popover.vue';
|
||||
import Popover from '~/vue_shared/components/help_popover.vue';
|
||||
|
||||
/**
|
||||
* Renders the summary row for each report
|
||||
|
|
@ -11,6 +11,8 @@ export const SUCCESS = 'SUCCESS';
|
|||
|
||||
export const STATUS_FAILED = 'failed';
|
||||
export const STATUS_SUCCESS = 'success';
|
||||
export const STATUS_NEUTRAL = 'neutral';
|
||||
|
||||
export const ICON_WARNING = 'warning';
|
||||
export const ICON_SUCCESS = 'success';
|
||||
export const ICON_NOTFOUND = 'notfound';
|
||||
|
|
|
|||
|
|
@ -1,3 +0,0 @@
|
|||
export const STATUS_FAILED = 'failed';
|
||||
export const STATUS_SUCCESS = 'success';
|
||||
export const STATUS_NEUTRAL = 'neutral';
|
||||
|
|
@ -103,6 +103,7 @@
|
|||
display: flex;
|
||||
|
||||
a {
|
||||
width: 100%;
|
||||
display: flex;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ label {
|
|||
}
|
||||
|
||||
.gl-show-field-errors {
|
||||
.form-control {
|
||||
.form-control:not(textarea) {
|
||||
height: 34px;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -253,7 +253,7 @@
|
|||
text-align: right;
|
||||
padding: 0;
|
||||
position: relative;
|
||||
top: -3px;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
.label-badge {
|
||||
|
|
@ -274,6 +274,7 @@
|
|||
|
||||
.label-links {
|
||||
list-style: none;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -823,10 +823,6 @@ pre.light-well {
|
|||
|
||||
.avatar-container {
|
||||
align-self: flex-start;
|
||||
|
||||
> a {
|
||||
width: 100%;
|
||||
}
|
||||
}
|
||||
|
||||
.project-details {
|
||||
|
|
|
|||
|
|
@ -301,3 +301,17 @@
|
|||
margin-bottom: 0;
|
||||
}
|
||||
}
|
||||
|
||||
.mirror-error-badge {
|
||||
background-color: $error-bg;
|
||||
border-radius: $border-radius-default;
|
||||
color: $white-light;
|
||||
}
|
||||
|
||||
.push-pull-table {
|
||||
margin-top: 1em;
|
||||
|
||||
.mirror-action-buttons {
|
||||
padding-right: 0;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,28 +1,10 @@
|
|||
module AvatarsHelper
|
||||
def project_icon(project_id, options = {})
|
||||
project =
|
||||
if project_id.respond_to?(:avatar_url)
|
||||
project_id
|
||||
else
|
||||
Project.find_by_full_path(project_id)
|
||||
end
|
||||
|
||||
if project.avatar_url
|
||||
image_tag project.avatar_url, options
|
||||
else # generated icon
|
||||
project_identicon(project, options)
|
||||
end
|
||||
source_icon(Project, project_id, options)
|
||||
end
|
||||
|
||||
def project_identicon(project, options = {})
|
||||
bg_key = (project.id % 7) + 1
|
||||
options[:class] ||= ''
|
||||
options[:class] << ' identicon'
|
||||
options[:class] << " bg#{bg_key}"
|
||||
|
||||
content_tag(:div, class: options[:class]) do
|
||||
project.name[0, 1].upcase
|
||||
end
|
||||
def group_icon(group_id, options = {})
|
||||
source_icon(Group, group_id, options)
|
||||
end
|
||||
|
||||
# Takes both user and email and returns the avatar_icon by
|
||||
|
|
@ -123,4 +105,32 @@ module AvatarsHelper
|
|||
mail_to(options[:user_email], avatar)
|
||||
end
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def source_icon(klass, source_id, options = {})
|
||||
source =
|
||||
if source_id.respond_to?(:avatar_url)
|
||||
source_id
|
||||
else
|
||||
klass.find_by_full_path(source_id)
|
||||
end
|
||||
|
||||
if source.avatar_url
|
||||
image_tag source.avatar_url, options
|
||||
else
|
||||
source_identicon(source, options)
|
||||
end
|
||||
end
|
||||
|
||||
def source_identicon(source, options = {})
|
||||
bg_key = (source.id % 7) + 1
|
||||
options[:class] ||= ''
|
||||
options[:class] << ' identicon'
|
||||
options[:class] << " bg#{bg_key}"
|
||||
|
||||
content_tag(:div, class: options[:class].strip) do
|
||||
source.name[0, 1].upcase
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -33,11 +33,6 @@ module GroupsHelper
|
|||
.count
|
||||
end
|
||||
|
||||
def group_icon(group, options = {})
|
||||
img_path = group_icon_url(group, options)
|
||||
image_tag img_path, options
|
||||
end
|
||||
|
||||
def group_icon_url(group, options = {})
|
||||
if group.is_a?(String)
|
||||
group = Group.find_by_full_path(group)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
module MirrorHelper
|
||||
def mirrors_form_data_attributes
|
||||
{ project_mirror_endpoint: project_mirror_path(@project) }
|
||||
end
|
||||
end
|
||||
|
|
@ -226,7 +226,7 @@ module Ci
|
|||
end
|
||||
|
||||
def cancelable?
|
||||
active?
|
||||
active? || created?
|
||||
end
|
||||
|
||||
def retryable?
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ProgrammingLanguage < ActiveRecord::Base
|
||||
validates :name, presence: true
|
||||
validates :color, allow_blank: false, color: true
|
||||
|
|
|
|||
|
|
@ -470,6 +470,24 @@ class Project < ActiveRecord::Base
|
|||
}x
|
||||
end
|
||||
|
||||
def reference_postfix
|
||||
'>'
|
||||
end
|
||||
|
||||
def reference_postfix_escaped
|
||||
'>'
|
||||
end
|
||||
|
||||
# Pattern used to extract `namespace/project>` project references from text.
|
||||
# '>' or its escaped form ('>') are checked for because '>' is sometimes escaped
|
||||
# when the reference comes from an external source.
|
||||
def markdown_reference_pattern
|
||||
%r{
|
||||
#{reference_pattern}
|
||||
(#{reference_postfix}|#{reference_postfix_escaped})
|
||||
}x
|
||||
end
|
||||
|
||||
def trending
|
||||
joins('INNER JOIN trending_projects ON projects.id = trending_projects.project_id')
|
||||
.reorder('trending_projects.id ASC')
|
||||
|
|
@ -908,6 +926,10 @@ class Project < ActiveRecord::Base
|
|||
end
|
||||
end
|
||||
|
||||
def to_reference_with_postfix
|
||||
"#{to_reference(full: true)}#{self.class.reference_postfix}"
|
||||
end
|
||||
|
||||
# `from` argument can be a Namespace or Project.
|
||||
def to_reference(from = nil, full: false)
|
||||
if full || cross_namespace_reference?(from)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'asana'
|
||||
|
||||
class AsanaService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AssemblaService < Service
|
||||
prop_accessor :token, :subdomain
|
||||
validates :token, presence: true, if: :activated?
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class BambooService < CiService
|
||||
include ReactiveService
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class BugzillaService < IssueTrackerService
|
||||
validates :project_url, :issues_url, :new_issue_url, presence: true, public_url: true, if: :activated?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require "addressable/uri"
|
||||
|
||||
class BuildkiteService < CiService
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# This class is to be removed with 9.1
|
||||
# We should also by then remove BuildsEmailService from database
|
||||
class BuildsEmailService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class CampfireService < Service
|
||||
prop_accessor :token, :subdomain, :room
|
||||
validates :token, presence: true, if: :activated?
|
||||
|
|
@ -82,7 +84,7 @@ class CampfireService < Service
|
|||
before = push[:before]
|
||||
after = push[:after]
|
||||
|
||||
message = ""
|
||||
message = []
|
||||
message << "[#{project.full_name}] "
|
||||
message << "#{push[:user_name]} "
|
||||
|
||||
|
|
@ -95,6 +97,6 @@ class CampfireService < Service
|
|||
message << "#{project.web_url}/compare/#{before}...#{after}"
|
||||
end
|
||||
|
||||
message
|
||||
message.join
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'slack-notifier'
|
||||
|
||||
module ChatMessage
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class IssueMessage < BaseMessage
|
||||
attr_reader :title
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class MergeMessage < BaseMessage
|
||||
attr_reader :merge_request_iid
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class NoteMessage < BaseMessage
|
||||
attr_reader :note
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class PipelineMessage < BaseMessage
|
||||
attr_reader :ref_type
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class PushMessage < BaseMessage
|
||||
attr_reader :after
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module ChatMessage
|
||||
class WikiPageMessage < BaseMessage
|
||||
attr_reader :title
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Base class for Chat notifications services
|
||||
# This class is not meant to be used directly, but only to inherit from.
|
||||
class ChatNotificationService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Base class for CI services
|
||||
# List methods you need to implement to get your CI service
|
||||
# working with GitLab Merge Requests
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class CustomIssueTrackerService < IssueTrackerService
|
||||
validates :project_url, :issues_url, :new_issue_url, presence: true, public_url: true, if: :activated?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Base class for deployment services
|
||||
#
|
||||
# These services integrate with a deployment solution like Kubernetes/OpenShift,
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class DroneCiService < CiService
|
||||
include ReactiveService
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class EmailsOnPushService < Service
|
||||
boolean_accessor :send_from_committer_email
|
||||
boolean_accessor :disable_diffs
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ExternalWikiService < Service
|
||||
prop_accessor :external_wiki_url
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require "flowdock-git-hook"
|
||||
|
||||
# Flow dock depends on Grit to compute the number of commits between two given
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require "gemnasium/gitlab_service"
|
||||
|
||||
class GemnasiumService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class GitlabIssueTrackerService < IssueTrackerService
|
||||
include Gitlab::Routing
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'hangouts_chat'
|
||||
|
||||
class HangoutsChatService < ChatNotificationService
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class HipchatService < Service
|
||||
include ActionView::Helpers::SanitizeHelper
|
||||
|
||||
|
|
@ -108,7 +110,7 @@ class HipchatService < Service
|
|||
before = push[:before]
|
||||
after = push[:after]
|
||||
|
||||
message = ""
|
||||
message = []
|
||||
message << "#{push[:user_name]} "
|
||||
|
||||
if Gitlab::Git.blank_ref?(before)
|
||||
|
|
@ -132,7 +134,7 @@ class HipchatService < Service
|
|||
end
|
||||
end
|
||||
|
||||
message
|
||||
message.join
|
||||
end
|
||||
|
||||
def markdown(text, options = {})
|
||||
|
|
@ -165,11 +167,11 @@ class HipchatService < Service
|
|||
description = obj_attr[:description]
|
||||
|
||||
issue_link = "<a href=\"#{issue_url}\">issue ##{issue_iid}</a>"
|
||||
message = "#{user_name} #{state} #{issue_link} in #{project_link}: <b>#{title}</b>"
|
||||
|
||||
message = ["#{user_name} #{state} #{issue_link} in #{project_link}: <b>#{title}</b>"]
|
||||
message << "<pre>#{markdown(description)}</pre>"
|
||||
|
||||
message
|
||||
message.join
|
||||
end
|
||||
|
||||
def create_merge_request_message(data)
|
||||
|
|
@ -184,12 +186,11 @@ class HipchatService < Service
|
|||
|
||||
merge_request_url = "#{project_url}/merge_requests/#{merge_request_id}"
|
||||
merge_request_link = "<a href=\"#{merge_request_url}\">merge request !#{merge_request_id}</a>"
|
||||
message = "#{user_name} #{state} #{merge_request_link} in " \
|
||||
"#{project_link}: <b>#{title}</b>"
|
||||
message = ["#{user_name} #{state} #{merge_request_link} in " \
|
||||
"#{project_link}: <b>#{title}</b>"]
|
||||
|
||||
message << "<pre>#{markdown(description)}</pre>"
|
||||
|
||||
message
|
||||
message.join
|
||||
end
|
||||
|
||||
def format_title(title)
|
||||
|
|
@ -235,12 +236,11 @@ class HipchatService < Service
|
|||
end
|
||||
|
||||
subject_html = "<a href=\"#{note_url}\">#{subject_type} #{subject_desc}</a>"
|
||||
message = "#{user_name} commented on #{subject_html} in #{project_link}: "
|
||||
message = ["#{user_name} commented on #{subject_html} in #{project_link}: "]
|
||||
message << title
|
||||
|
||||
message << "<pre>#{markdown(note, ref: commit_id)}</pre>"
|
||||
|
||||
message
|
||||
message.join
|
||||
end
|
||||
|
||||
def create_pipeline_message(data)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'uri'
|
||||
|
||||
class IrkerService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class IssueTrackerService < Service
|
||||
validate :one_issue_tracker, if: :activated?, on: :manual_change
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class JiraService < IssueTrackerService
|
||||
include Gitlab::Routing
|
||||
include ApplicationHelper
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
##
|
||||
# NOTE:
|
||||
# We'll move this class to Clusters::Platforms::Kubernetes, which contains exactly the same logic.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class MattermostService < ChatNotificationService
|
||||
def title
|
||||
'Mattermost notifications'
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class MattermostSlashCommandsService < SlashCommandsService
|
||||
include TriggersHelper
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class MicrosoftTeamsService < ChatNotificationService
|
||||
def title
|
||||
'Microsoft Teams Notification'
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# For an example companion mocking service, see https://gitlab.com/gitlab-org/gitlab-mock-ci-service
|
||||
class MockCiService < CiService
|
||||
ALLOWED_STATES = %w[failed canceled running pending success success_with_warnings skipped not_found].freeze
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class MockDeploymentService < DeploymentService
|
||||
def title
|
||||
'Mock deployment'
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class MockMonitoringService < MonitoringService
|
||||
def title
|
||||
'Mock monitoring'
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Base class for monitoring services
|
||||
#
|
||||
# These services integrate with a deployment solution like Prometheus
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class PackagistService < Service
|
||||
prop_accessor :username, :token, :server
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class PipelinesEmailService < Service
|
||||
prop_accessor :recipients
|
||||
boolean_accessor :notify_only_broken_pipelines
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class PivotaltrackerService < Service
|
||||
API_ENDPOINT = 'https://www.pivotaltracker.com/services/v5/source_commits'.freeze
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class PrometheusService < MonitoringService
|
||||
include PrometheusAdapter
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class PushoverService < Service
|
||||
BASE_URI = 'https://api.pushover.net/1'.freeze
|
||||
|
||||
|
|
@ -79,7 +81,7 @@ class PushoverService < Service
|
|||
end
|
||||
|
||||
if data[:total_commits_count] > 0
|
||||
message << "\nTotal commits count: #{data[:total_commits_count]}"
|
||||
message = [message, "Total commits count: #{data[:total_commits_count]}"].join("\n")
|
||||
end
|
||||
|
||||
pushover_data = {
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class RedmineService < IssueTrackerService
|
||||
validates :project_url, :issues_url, :new_issue_url, presence: true, public_url: true, if: :activated?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class SlackService < ChatNotificationService
|
||||
def title
|
||||
'Slack notifications'
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class SlackSlashCommandsService < SlashCommandsService
|
||||
include TriggersHelper
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
# Base class for Chat services
|
||||
# This class is not meant to be used directly, but only to inherrit from.
|
||||
class SlashCommandsService < Service
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class TeamcityService < CiService
|
||||
include ReactiveService
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ProtectedBranch::MergeAccessLevel < ActiveRecord::Base
|
||||
include ProtectedBranchAccess
|
||||
end
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ProtectedBranch::PushAccessLevel < ActiveRecord::Base
|
||||
include ProtectedBranchAccess
|
||||
end
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class ProtectedTag::CreateAccessLevel < ActiveRecord::Base
|
||||
include ProtectedTagAccess
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class RepositoryLanguage < ActiveRecord::Base
|
||||
belongs_to :project
|
||||
belongs_to :programming_language
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class SiteStatistic < ActiveRecord::Base
|
||||
# prevents the creation of multiple rows
|
||||
default_value_for :id, 1
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Storage
|
||||
class HashedProject
|
||||
attr_accessor :project
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Storage
|
||||
class LegacyProject
|
||||
attr_accessor :project
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
class ProjectMirrorSerializer < BaseSerializer
|
||||
entity ProjectMirrorEntity
|
||||
end
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
.bordered-box.fork-thumbnail.text-center.prepend-left-default.append-right-default.prepend-top-default.append-bottom-default.forked
|
||||
= link_to project_path(forked_project) do
|
||||
- if /no_((\w*)_)*avatar/.match(avatar)
|
||||
= project_identicon(namespace, class: "avatar s100 identicon")
|
||||
= project_icon(namespace, class: "avatar s100 identicon")
|
||||
- else
|
||||
.avatar-container.s100
|
||||
= image_tag(avatar, class: "avatar s100")
|
||||
|
|
@ -18,7 +18,7 @@
|
|||
class: ("disabled has-tooltip" unless can_create_project),
|
||||
title: (_('You have reached your project limit') unless can_create_project) do
|
||||
- if /no_((\w*)_)*avatar/.match(avatar)
|
||||
= project_identicon(namespace, class: "avatar s100 identicon")
|
||||
= project_icon(namespace, class: "avatar s100 identicon")
|
||||
- else
|
||||
.avatar-container.s100
|
||||
= image_tag(avatar, class: "avatar s100")
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
.account-well.prepend-top-default.append-bottom-default
|
||||
%ul
|
||||
%li
|
||||
The repository must be accessible over <code>http://</code>, <code>https://</code>, <code>ssh://</code> or <code>git://</code>.
|
||||
= _('The repository must be accessible over <code>http://</code>,
|
||||
<code>https://</code>, <code>ssh://</code> and <code>git://</code>.').html_safe
|
||||
%li= _('Include the username in the URL if required: <code>https://username@gitlab.company.com/group/project.git</code>.').html_safe
|
||||
%li= _('The update action will time out after 15 minutes. For big repositories, use a clone/push combination.')
|
||||
%li= _('The Git LFS objects will <strong>not</strong> be synced.').html_safe
|
||||
%li
|
||||
Include the username in the URL if required: <code>https://username@gitlab.company.com/group/project.git</code>.
|
||||
%li
|
||||
The update action will time out after 10 minutes. For big repositories, use a clone/push combination.
|
||||
%li
|
||||
The Git LFS objects will <strong>not</strong> be synced.
|
||||
= _('This user will be the author of all events in the activity feed that are the result of an update,
|
||||
like new branches being created or new commits being pushed to existing branches.')
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
- expanded = Rails.env.test?
|
||||
- protocols = Gitlab::UrlSanitizer::ALLOWED_SCHEMES.join('|')
|
||||
|
||||
%section.settings.project-mirror-settings.js-mirror-settings.no-animate{ class: ('expanded' if expanded) }
|
||||
.settings-header
|
||||
%h4= _('Mirroring repositories')
|
||||
%button.btn.js-settings-toggle
|
||||
= expanded ? _('Collapse') : _('Expand')
|
||||
%p
|
||||
= _('Set up your project to automatically push and/or pull changes to/from another repository. Branches, tags, and commits will be synced automatically.')
|
||||
= link_to _('Read more'), help_page_path('workflow/repository_mirroring'), target: '_blank'
|
||||
|
||||
.settings-content
|
||||
= form_for @project, url: project_mirror_path(@project), html: { class: 'gl-show-field-errors js-mirror-form', autocomplete: 'false', data: mirrors_form_data_attributes } do |f|
|
||||
.panel.panel-default
|
||||
.panel-heading
|
||||
%h3.panel-title= _('Mirror a repository')
|
||||
.panel-body
|
||||
%div= form_errors(@project)
|
||||
|
||||
.form-group.has-feedback
|
||||
= label_tag :url, _('Git repository URL'), class: 'label-light'
|
||||
= text_field_tag :url, nil, class: 'form-control js-mirror-url js-repo-url', placeholder: _('Input your repository URL'), required: true, pattern: "(#{protocols}):\/\/.+"
|
||||
|
||||
= render 'projects/mirrors/instructions'
|
||||
|
||||
= render 'projects/mirrors/mirror_repos_form', f: f
|
||||
|
||||
.form-check.append-bottom-10
|
||||
= check_box_tag :only_protected_branches, '1', false, class: 'js-mirror-protected form-check-input'
|
||||
= label_tag :only_protected_branches, _('Only mirror protected branches'), class: 'form-check-label'
|
||||
= link_to icon('question-circle'), help_page_path('user/project/protected_branches')
|
||||
|
||||
.panel-footer
|
||||
= f.submit _('Mirror repository'), class: 'btn btn-create', name: :update_remote_mirror
|
||||
|
||||
.panel.panel-default
|
||||
.table-responsive
|
||||
%table.table.push-pull-table
|
||||
%thead
|
||||
%tr
|
||||
%th
|
||||
= _('Mirrored repositories')
|
||||
= render_if_exists 'projects/mirrors/mirrored_repositories_count'
|
||||
%th= _('Direction')
|
||||
%th= _('Last update')
|
||||
%th
|
||||
%th
|
||||
%tbody.js-mirrors-table-body
|
||||
= render_if_exists 'projects/mirrors/table_pull_row'
|
||||
- @project.remote_mirrors.each_with_index do |mirror, index|
|
||||
- if mirror.enabled
|
||||
%tr
|
||||
%td= mirror.safe_url
|
||||
%td= _('Push')
|
||||
%td= mirror.last_update_at.present? ? time_ago_with_tooltip(mirror.last_update_at) : _('Never')
|
||||
%td
|
||||
- if mirror.last_error.present?
|
||||
.badge.mirror-error-badge{ data: { toggle: 'tooltip', html: 'true' }, title: html_escape(mirror.last_error.try(:strip)) }= _('Error')
|
||||
%td.mirror-action-buttons
|
||||
.btn-group.mirror-actions-group.pull-right{ role: 'group' }
|
||||
= render 'shared/remote_mirror_update_button', remote_mirror: mirror
|
||||
%button.js-delete-mirror.btn.btn-danger{ type: 'button', data: { mirror_id: mirror.id, toggle: 'tooltip', container: 'body' }, title: _('Remove') }= icon('trash-o')
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
- protocols = Gitlab::UrlSanitizer::ALLOWED_SCHEMES.join('|')
|
||||
|
||||
.form-group
|
||||
= label_tag :mirror_direction, _('Mirror direction'), class: 'label-light'
|
||||
= select_tag :mirror_direction, options_for_select([[_('Push'), 'push']]), class: 'form-control js-mirror-direction', disabled: true
|
||||
|
||||
= f.fields_for :remote_mirrors, @project.remote_mirrors.build do |rm_f|
|
||||
= rm_f.hidden_field :enabled, value: '1'
|
||||
= rm_f.hidden_field :url, class: 'js-mirror-url-hidden', required: true, pattern: "(#{protocols}):\/\/.+"
|
||||
= rm_f.hidden_field :only_protected_branches, class: 'js-mirror-protected-hidden'
|
||||
|
||||
.form-group
|
||||
= label_tag :auth_method, _('Authentication method'), class: 'label-bold'
|
||||
= select_tag :auth_method, options_for_select([[_('None'), 'none'], [_('Password'), 'password']], 'none'), { class: "form-control js-auth-method" }
|
||||
|
||||
.form-group.js-password-group.collapse
|
||||
= label_tag :password, _('Password'), class: 'label-bold'
|
||||
= text_field_tag :password, '', class: 'form-control js-password'
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
- expanded = Rails.env.test?
|
||||
%section.settings.no-animate#js-push-remote-settings{ class: ('expanded' if expanded) }
|
||||
.settings-header
|
||||
%h4
|
||||
Push to a remote repository
|
||||
%button.btn.js-settings-toggle
|
||||
= expanded ? 'Collapse' : 'Expand'
|
||||
%p
|
||||
Set up the remote repository that you want to update with the content of the current repository
|
||||
every time someone pushes to it.
|
||||
= link_to 'Read more', help_page_path('workflow/repository_mirroring', anchor: 'pushing-to-a-remote-repository'), target: '_blank'
|
||||
.settings-content
|
||||
= form_for @project, url: project_mirror_path(@project) do |f|
|
||||
%div
|
||||
= form_errors(@project)
|
||||
= render "shared/remote_mirror_update_button", remote_mirror: @remote_mirror
|
||||
- if @remote_mirror.last_error.present?
|
||||
.panel.panel-danger
|
||||
.panel-heading
|
||||
- if @remote_mirror.last_update_at
|
||||
The remote repository failed to update #{time_ago_with_tooltip(@remote_mirror.last_update_at)}.
|
||||
- else
|
||||
The remote repository failed to update.
|
||||
|
||||
- if @remote_mirror.last_successful_update_at
|
||||
Last successful update #{time_ago_with_tooltip(@remote_mirror.last_successful_update_at)}.
|
||||
.panel-body
|
||||
%pre
|
||||
:preserve
|
||||
#{h(@remote_mirror.last_error.strip)}
|
||||
= f.fields_for :remote_mirrors, @remote_mirror do |rm_form|
|
||||
.form-group
|
||||
= rm_form.check_box :enabled, class: "float-left"
|
||||
.prepend-left-20
|
||||
= rm_form.label :enabled, "Remote mirror repository", class: "label-bold append-bottom-0"
|
||||
%p.light.append-bottom-0
|
||||
Automatically update the remote mirror's branches, tags, and commits from this repository every time someone pushes to it.
|
||||
.form-group.has-feedback
|
||||
= rm_form.label :url, "Git repository URL", class: "label-bold"
|
||||
= rm_form.text_field :url, class: "form-control", placeholder: 'https://username:password@gitlab.company.com/group/project.git'
|
||||
|
||||
= render "projects/mirrors/instructions"
|
||||
|
||||
.form-group
|
||||
= rm_form.check_box :only_protected_branches, class: 'float-left'
|
||||
.prepend-left-20
|
||||
= rm_form.label :only_protected_branches, class: 'label-bold'
|
||||
= link_to icon('question-circle'), help_page_path('user/project/protected_branches')
|
||||
|
||||
= f.submit 'Save changes', class: 'btn btn-create', name: 'update_remote_mirror'
|
||||
|
|
@ -1,3 +1 @@
|
|||
- if can?(current_user, :admin_remote_mirror, @project)
|
||||
= render 'projects/mirrors/push'
|
||||
|
||||
= render 'projects/mirrors/mirror_repos'
|
||||
|
|
|
|||
|
|
@ -1,13 +1,6 @@
|
|||
- if @project.has_remote_mirror?
|
||||
.append-bottom-default
|
||||
- if remote_mirror.update_in_progress?
|
||||
%span.btn.disabled
|
||||
= icon("refresh spin")
|
||||
Updating…
|
||||
- else
|
||||
= link_to update_now_project_mirror_path(@project, sync_remote: true), method: :post, class: "btn" do
|
||||
= icon("refresh")
|
||||
Update Now
|
||||
- if @remote_mirror.last_successful_update_at
|
||||
%p.inline.prepend-left-10
|
||||
Successfully updated #{time_ago_with_tooltip(@remote_mirror.last_successful_update_at)}.
|
||||
- if remote_mirror.update_in_progress?
|
||||
%button.btn.disabled{ type: 'button', data: { toggle: 'tooltip', container: 'body' }, title: _('Updating') }
|
||||
= icon("refresh spin")
|
||||
- else
|
||||
= link_to update_now_project_mirror_path(@project, sync_remote: true), method: :post, class: "btn", data: { toggle: 'tooltip', container: 'body' }, title: _('Update now') do
|
||||
= icon("refresh")
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
title: First Improvements made to the contributor on-boarding experience.
|
||||
merge_request: 20682
|
||||
author: Eddie Stubbington
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add the ability to reference projects in comments and other markdown text.
|
||||
merge_request: 20285
|
||||
author: Reuben Pereira
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Allows to cancel a Created job
|
||||
merge_request: 20635
|
||||
author: Jacopo Beschi @jacopo-beschi
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add default avatar to group
|
||||
merge_request: 17271
|
||||
author: George Tsiolis
|
||||
type: changed
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix label list item container height when there is no label description
|
||||
merge_request: 21106
|
||||
author:
|
||||
type: fixed
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Enable frozen string in rest of app/models/**/*.rb
|
||||
merge_request: gfyoung
|
||||
author:
|
||||
type: performance
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix empty merge requests not opening in the Web IDE
|
||||
merge_request: 21102
|
||||
author:
|
||||
type: fixed
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Rails5 fix specs duplicate key value violates unique constraint 'index_gpg_signatures_on_commit_sha'
|
||||
merge_request: 21119
|
||||
author: Jasper Maes
|
||||
type: fixed
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue