Fall back to In-Reply-To and References headers when sub-addressing is not available
_Originally opened at !3024 by @dabit._
- - -
Fixes#2364
Summary of the changes:
- No more need to have the `%{key}` placeholder in the `incoming_email.address`
- The fallback message id format is `reply-[key]@[gitlab_host]` (reminder: it doesn't have to be a real email address)
- The fallback message id that includes the reply key is added to both `References` header
- Documentation for the "Reply by email" feature updated
See merge request !3305
Update ldap docs
Related to gitlab-org/gitlab-ee#397
@axil What do you think of moving LDAP configuration docs to `adminstration/auth/ldap.md`? Then we'll probably need to add the relevant group link configuration piece to some user group documentation. We can cross-link and deprecate the current `integration/ldap.md` location.
See merge request !3336
A few things to note:
- The IncomingEmail feature is now enabled even without a
correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
notifications to this thread are grouped in the thread by the email
service that receives the notification
(i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
Clarify LFS configuration
A user on Twitter was confused (rightfully so) because LFS admin docs suggest you must set a storage path. In fact, Omnibus defaults to a very sane location. Add a comment to the snippet outlining the default.
See merge request !3388
Grafana installation and configuration documentation
Adding documentation for installing and configuring Grafana. This also includes providing dashboards users can import.
Fixes gitlab-org/omnibus-gitlab#1008
cc/ @axil
See merge request !3015
Reload the schema before restoring a database backup
If a user tries to downgrade and restore after a failed upgrade,
the database may still contain newer tables. Reload the older
schema before restoring the database to avoid future upgrade
problems. Also, add a rake task to help users add migration
versions to the database so it's easier to recover from these
errors if they do occur. Fixes#13419
See merge request !2807
GitLab intro docs
Related to https://gitlab.com/gitlab-org/marketing_monthly_release/issues/1
---
Need refactor:
- Create a new project
- Create a new group
- Create a new issue
- Assign labels to issues
- Use milestones as an overview of your project's tracker
- Fork a project and contribute to it
- Create a new merge request
- Automatically close issues from merge requests (include GitLab.com pattern)
- GitLab CI quick start guide (make it easier to follow)
Moved to https://gitlab.com/gitlab-org/gitlab-ce/issues/8068
See merge request !3225
CI: Add 'triggers' keyword to 'only' and 'except' lists to allow control over when triggers cause builds to run
Currently, the `only` and `except` keywords in `.gitlab-ci.yml` only accept ref names or the special `branches` and `tags` keywords. However, these are primarily useful when controlling how repository activity affects the creation of builds. In my case, instead of building on every commit, I'd like to use the following logic:
- If the repository is tagged, do a build.
- Any other normal commits should not cause a build.
- If a build is triggered via the API, always create one for the specified ref.
From what I can tell, this isn't possible via the existing YAML syntax. In this MR, I introduce a new keyword `triggers` that goes along with `branches` and `tags`. I can implement the logic above using the following job configuration:
```yaml
only:
- tags
- triggers
```
I updated the tests and documentation to reflect this and everything seems to pass.
See merge request !3230