Коммит 7e02921d создал по автору Marcel Amirault's avatar Marcel Amirault
Просмотр файлов

Proof of concept linting outside docs dir 

Shows how much work is required to enable linting on docs
changes outside the /docs dir, if required in the future
владелец e7ac3a24
Скрыть пробелы
Построчно Рядом
.gitlab/ci/docs.gitlab-ci.yml
Просмотр файла @ 7e02921d
......@@ -74,7 +74,7 @@ docs lint:
script:
- scripts/lint-doc.sh
# Lint Markdown
- markdownlint --config .markdownlint.json 'doc/**/*.md'
- markdownlint --config .markdownlint.json --ignore={'CHANGELOG.md','changelogs/archive.md'} '**/*.md'
# Prepare docs for build
- mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX
- cd /tmp/gitlab-docs
......
CONTRIBUTING.md
Просмотр файла @ 7e02921d
## Developer Certificate of Origin + License
# Developer Certificate of Origin + License
By contributing to GitLab B.V., You accept and agree to the following terms and
conditions for Your present and future Contributions submitted to GitLab B.V.
......@@ -40,7 +40,7 @@ This [documentation](doc/development/contributing/index.md#closing-policy-for-is
This [documentation](doc/development/contributing/index.md#helping-others) has been moved.
## I want to contribute!
## I want to contribute
[View the new documentation](https://about.gitlab.com/community/contribute/) to find the latest information.
......
PROCESS.md
Просмотр файла @ 7e02921d
## GitLab core team & GitLab Inc. contribution process
# GitLab core team & GitLab Inc. contribution process
---
......@@ -56,7 +56,7 @@ Below we describe the contributing process to GitLab for two reasons:
Several people from the [GitLab team][team] are helping community members to get
their contributions accepted by meeting our [Definition of done][done].
What you can expect from them is described at https://about.gitlab.com/job-families/expert/merge-request-coach/.
What you can expect from them is described at <https://about.gitlab.com/job-families/expert/merge-request-coach/>.
### Milestones on community contribution issues
......@@ -111,16 +111,16 @@ deployed to GitLab.com prior to this date.
These types of merge requests for the upcoming release need special consideration:
* **Large features**: a large feature is one that is highlighted in the kick-off
- **Large features**: a large feature is one that is highlighted in the kick-off
and the release blogpost; typically this will have its own channel in Slack
and a dedicated team with front-end, back-end, and UX.
* **Small features**: any other feature request.
- **Small features**: any other feature request.
It is strongly recommended that **large features** be with a maintainer **by the
1st**. This means that:
* There is a merge request (even if it's WIP).
* The person (or people, if it needs a frontend and backend maintainer) who will
- There is a merge request (even if it's WIP).
- The person (or people, if it needs a frontend and backend maintainer) who will
ultimately be responsible for merging this have been pinged on the MR.
It's OK if merge request isn't completely done, but this allows the maintainer
......@@ -195,12 +195,12 @@ information, see
Once the stable branch is frozen, the only MRs that can be cherry-picked into
the stable branch are:
* Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section.
* Fixes for security issues.
* Fixes or improvements to automated QA scenarios.
* [Documentation improvements](https://docs.gitlab.com/ee/development/documentation/workflow.html) for feature changes made in the same release, though initial docs for these features should have already been merged by the freeze, as required.
* New or updated translations (as long as they do not touch application code).
* Changes that are behind a feature flag and have the ~"feature flag" label.
- Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section.
- Fixes for security issues.
- Fixes or improvements to automated QA scenarios.
- [Documentation improvements](https://docs.gitlab.com/ee/development/documentation/workflow.html) for feature changes made in the same release, though initial docs for these features should have already been merged by the freeze, as required.
- New or updated translations (as long as they do not touch application code).
- Changes that are behind a feature flag and have the ~"feature flag" label.
During the feature freeze all merge requests that are meant to go into the
upcoming release should have the correct milestone assigned _and_ the
......@@ -256,15 +256,17 @@ Regressions should be considered high priority issues that should be solved as s
### Managing bugs
**Prioritization:** We give higher priority to regressions on features that worked in the last recent monthly release and the current release candidates.
The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version.
* A regression which worked in the **Last monthly release**
* **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
* *Note:* When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
* A regression which worked in the **Current release candidates**
* **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
* *Note:* Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month.
The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version:
- A regression which worked in the **Last monthly release**
- **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
- *Note:* When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
- A regression which worked in the **Current release candidates**
- **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
- *Note:* Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month.
When a bug is found:
1. Create an issue describing the problem in the most detailed way possible.
1. If possible, provide links to real examples and how to reproduce the problem.
1. Label the issue properly, by respecting the [Partial triage level](https://about.gitlab.com/handbook/engineering/issue-triage/#partial-triage).
......
README.md
Просмотр файла @ 7e02921d
......@@ -70,7 +70,9 @@ To work on GitLab itself, we recommend setting up your development environment w
If you do not use the GitLab Development Kit you need to install and setup all the dependencies yourself, this is a lot of work and error prone.
One small thing you also have to do when installing it yourself is to copy the example development unicorn configuration file:
cp config/unicorn.rb.example.development config/unicorn.rb
```sh
cp config/unicorn.rb.example.development config/unicorn.rb
```
Instructions on how to start GitLab and how to run the tests can be found in the [getting started section of the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit#getting-started).
......
app/presenters/README.md
Просмотр файла @ 7e02921d
......@@ -24,7 +24,7 @@ Presenters should be used for:
- Data and logic methods that can be pulled & combined into single methods from
view. This can include loops extracted from views too. A good example is
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7073/diffs.
<https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7073/diffs>.
- Data and logic methods that can be pulled from models.
- Simple text output methods: it's ok if the method returns a string, but not a
whole DOM element for which we'd need HAML, a view context, helpers etc.
......@@ -42,7 +42,7 @@ Nonetheless, the main issue is that concerns don’t make the model object more
cohesive. The code is just better organized. In other words, there’s no real
change to the API of the model.
– https://www.toptal.com/ruby-on-rails/decoupling-rails-components
– <https://www.toptal.com/ruby-on-rails/decoupling-rails-components>
## Benefits
......
app/serializers/README.md
Просмотр файла @ 7e02921d
......@@ -12,15 +12,15 @@ that is usually consumed by a frontend code.
Using serializers, instead of `to_json` method, has several benefits:
* it helps to prevent exposure of a sensitive data stored in the database
* it makes it easier to test what should and should not be exposed
* it makes it easier to reuse serialization entities that are building blocks
* it makes it easier to move complexity from controllers to easily testable
- it helps to prevent exposure of a sensitive data stored in the database
- it makes it easier to test what should and should not be exposed
- it makes it easier to reuse serialization entities that are building blocks
- it makes it easier to move complexity from controllers to easily testable
classes
* it encourages hiding complexity behind intentions-revealing interfaces
* it makes it easier to take care about serialization performance concerns
* it makes it easier to reduce merge conflicts between CE -> EE
* it makes it easier to benefit from domain driven development techniques
- it encourages hiding complexity behind intentions-revealing interfaces
- it makes it easier to take care about serialization performance concerns
- it makes it easier to reduce merge conflicts between CE -> EE
- it makes it easier to benefit from domain driven development techniques
## What is a serializer?
......@@ -250,57 +250,57 @@ MyObjectSerializer.new.represent(object.present)
1. Do not invoke a serializer from within a serialization entity.
If you need to use a serializer from within a serialization entity, it is
possible that you are missing a class for an important domain concept.
If you need to use a serializer from within a serialization entity, it is
possible that you are missing a class for an important domain concept.
Consider creating a new domain class and a corresponding serialization
entity for it.
Consider creating a new domain class and a corresponding serialization
entity for it.
1. Use only one approach to switch behavior of the serializer.
It is possible to use a few approaches to switch a behavior of the
serializer. Most common are using a [Fluent Interface][fluent-interface]
and creating a separate `represent_something` methods.
It is possible to use a few approaches to switch a behavior of the
serializer. Most common are using a [Fluent Interface][fluent-interface]
and creating a separate `represent_something` methods.
Whatever you choose, it might be better to use only one approach at a time.
Whatever you choose, it might be better to use only one approach at a time.
1. Do not forget about creating specs for serialization entities.
Writing tests for the serializer indeed does cover testing a behavior of
serialization entities that the serializer instantiates. However it might
be a good idea to write separate tests for entities as well, because these
are meant to be reused in different serializers, and a serializer can
change a behavior of a serialization entity.
Writing tests for the serializer indeed does cover testing a behavior of
serialization entities that the serializer instantiates. However it might
be a good idea to write separate tests for entities as well, because these
are meant to be reused in different serializers, and a serializer can
change a behavior of a serialization entity.
1. Use `ActiveRecord::Relation` where possible
Using an `ActiveRecord::Relation` might help from the performance perspective.
Using an `ActiveRecord::Relation` might help from the performance perspective.
1. Be diligent about passing an additional context from the controller.
Using `EntityRequest` and `RequestAwareEntity` is a workaround for the lack
of high-level mechanism. It is meant to be refactored, and current
implementation is error prone. Imagine the situation that one serialization
entity requires `request.user` attribute, but the second one wants
`request.current_user`. When it happens that these two entities are used in
the same serialization request, you might need to pass both parameters to
the serializer, which is obviously not a perfect situation.
Using `EntityRequest` and `RequestAwareEntity` is a workaround for the lack
of high-level mechanism. It is meant to be refactored, and current
implementation is error prone. Imagine the situation that one serialization
entity requires `request.user` attribute, but the second one wants
`request.current_user`. When it happens that these two entities are used in
the same serialization request, you might need to pass both parameters to
the serializer, which is obviously not a perfect situation.
When in doubt, pass only `current_user` and `project` if these are required.
When in doubt, pass only `current_user` and `project` if these are required.
1. Keep performance concerns in mind
Using a serializer incorrectly can have significant impact on the
performance.
Using a serializer incorrectly can have significant impact on the
performance.
Because serializers are technically presenters, it is often necessary
to calculate, for example, paths to various controller-actions.
Since using URL helpers usually involve passing `project` and `namespace`
adding `includes(project: :namespace)` in the serializer, can help to avoid
N+1 queries.
Because serializers are technically presenters, it is often necessary
to calculate, for example, paths to various controller-actions.
Since using URL helpers usually involve passing `project` and `namespace`
adding `includes(project: :namespace)` in the serializer, can help to avoid
N+1 queries.
Also, try to avoid using `Enumerable#map` or other methods that will
execute a database query eagerly.
Also, try to avoid using `Enumerable#map` or other methods that will
execute a database query eagerly.
1. Avoid passing `only` and `except` from the controller.
1. Write tests checking for N+1 queries.
......@@ -310,7 +310,7 @@ MyObjectSerializer.new.represent(object.present)
## Future
* [Next iteration of serializers][issue-27569]
- [Next iteration of serializers][issue-27569]
[grape-project]: http://www.ruby-grape.org
[grape-entity-project]: https://github.com/ruby-grape/grape-entity
......
config/README.md
Просмотр файла @ 7e02921d
......@@ -21,7 +21,7 @@ This file is called `resque.yml` for historical reasons. We are **NOT**
using Resque at the moment. It is used to specify Redis configuration
values when a single database instance of Redis is desired.
# Advanced Redis configuration files
## Advanced Redis configuration files
In more advanced configurations of Redis key-value storage, it is desirable
to separate the keys by lifecycle and intended use to ease provisioning and
......@@ -32,27 +32,29 @@ persistence policies, and other Redis customization) for connections
to Redis single instances, Redis sentinel, and Redis clusters.
If desired, the routing URL provided by these settings can be used with:
1. Unix Socket
1. named socket for each Redis instance desired.
2. `database number` for each Redis instance desired.
2. TCP Socket
1. `host name` or IP for each Redis instance desired
2. TCP port number for each Redis instance desired
3. `database number` for each Redis instance desired
## Example URL attribute formats for GitLab Redis `.yml` configuration files
* Unix Socket, default Redis database (0)
* `url: unix:/path/to/redis.sock`
* `url: unix:/path/to/redis.sock?db=`
* Unix Socket, Redis database 44
* `url: unix:/path/to/redis.sock?db=44`
* `url: unix:/path/to/redis.sock?extra=foo&db=44`
* TCP Socket for Redis on localhost, port 6379, database 33
* `url: redis://:mynewpassword@localhost:6379/33`
* TCP Socket for Redis on remote host `myserver`, port 6379, database 33
* `url: redis://:mynewpassword@myserver:6379/33`
## redis.cache.yml
1. named socket for each Redis instance desired.
1. `database number` for each Redis instance desired.
1. TCP Socket
1. `host name` or IP for each Redis instance desired
1. TCP port number for each Redis instance desired
1. `database number` for each Redis instance desired
### Example URL attribute formats for GitLab Redis `.yml` configuration files
- Unix Socket, default Redis database (0)
- `url: unix:/path/to/redis.sock`
- `url: unix:/path/to/redis.sock?db=`
- Unix Socket, Redis database 44
- `url: unix:/path/to/redis.sock?db=44`
- `url: unix:/path/to/redis.sock?extra=foo&db=44`
- TCP Socket for Redis on localhost, port 6379, database 33
- `url: redis://:mynewpassword@localhost:6379/33`
- TCP Socket for Redis on remote host `myserver`, port 6379, database 33
- `url: redis://:mynewpassword@myserver:6379/33`
### redis.cache.yml
If configured, `redis.cache.yml` overrides the
`resque.yml` settings to configure the Redis database instance
......@@ -64,26 +66,28 @@ an alternate location for configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for `cache` is:
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
2. URL from `redis.cache.yml`
3. URL from a configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. URL from `resque.yml`
5. `redis://localhost:6380`
`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
1. URL from `redis.cache.yml`
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
1. URL from `resque.yml`
1. `redis://localhost:6380`
The order of precedence for all other configuration settings for `cache`
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
1. the configuration file pointed to by the
`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
2. the configuration file `redis.cache.yml`
3. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. the configuration file `resque.yml`
`GITLAB_REDIS_CACHE_CONFIG_FILE` environment variable
1. the configuration file `redis.cache.yml`
1. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
1. the configuration file `resque.yml`
## redis.queues.yml
### redis.queues.yml
If configured, `redis.queues.yml` overrides the
`resque.yml` settings to configure the Redis database instance
......@@ -98,26 +102,28 @@ configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for `queues` is:
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
1. URL from `redis.queues.yml`
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
2. URL from `redis.queues.yml`
3. URL from a configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. URL from `resque.yml`
5. `redis://localhost:6381`
1. URL from `resque.yml`
1. `redis://localhost:6381`
The order of precedence for all other configuration settings for `queues`
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
1. the configuration file pointed to by the
`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
2. the configuration file `redis.queues.yml`
3. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. the configuration file `resque.yml`
`GITLAB_REDIS_QUEUES_CONFIG_FILE` environment variable
1. the configuration file `redis.queues.yml`
1. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
1. the configuration file `resque.yml`
## redis.shared_state.yml
### redis.shared_state.yml
If configured, `redis.shared_state.yml` overrides the
`resque.yml` settings to configure the Redis database instance
......@@ -129,21 +135,23 @@ an alternate location for configuration settings.
The order of precedence for the URL used to connect to the Redis instance
used for `shared_state` is:
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
2. URL from `redis.shared_state.yml`
3. URL from a configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. URL from `resque.yml`
5. `redis://localhost:6382`
`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
1. URL from `redis.shared_state.yml`
1. URL from a configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
1. URL from `resque.yml`
1. `redis://localhost:6382`
The order of precedence for all other configuration settings for `shared_state`
are selected from only the first of the following files found (if a setting
is not provided in an earlier file, the remainder of the files are not
searched):
1. the configuration file pointed to by the
`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
2. the configuration file `redis.shared_state.yml`
3. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
4. the configuration file `resque.yml`
`GITLAB_REDIS_SHARED_STATE_CONFIG_FILE` environment variable
1. the configuration file `redis.shared_state.yml`
1. the configuration file pointed to by the
`GITLAB_REDIS_CONFIG_FILE` environment variable
1. the configuration file `resque.yml`
qa/README.md
Просмотр файла @ 7e02921d
......@@ -70,9 +70,9 @@ will need to [modify your GDK setup](https://gitlab.com/gitlab-org/gitlab-qa/blo
### Writing tests
- [Writing tests from scratch tutorial](../doc/development/testing_guide/end_to_end/quick_start_guide.md)
- [Best practices](../doc/development/testing_guide/best_practices.md)
- [Using page objects](../doc/development/testing_guide/end_to_end/page_objects.md)
- [Guidelines](../doc/development/testing_guide/index.md)
- [Best practices](../doc/development/testing_guide/best_practices.md)
- [Using page objects](../doc/development/testing_guide/end_to_end/page_objects.md)
- [Guidelines](../doc/development/testing_guide/index.md)
### Running specific tests
......@@ -134,7 +134,6 @@ canary fleet. To do this set `QA_COOKIES="gitlab_canary=true"`.
To set multiple cookies, separate them with the `;` character, for example: `QA_COOKIES="cookie1=value;cookie2=value2"`
### Building a Docker image to test
Once you have made changes to the CE/EE repositories, you may want to build a
......
spec/fixtures/blockquote_fence_after.md
Просмотр файла @ 7e02921d
......@@ -18,13 +18,10 @@ Double `>>>` inside code block:
Blockquote outside code block:
> Quote
Code block inside blockquote:
> Quote
>
> ```
......@@ -33,10 +30,8 @@ Code block inside blockquote:
>
> Quote
Single `>>>` inside code block inside blockquote:
> Quote
>
> ```
......@@ -47,10 +42,8 @@ Single `>>>` inside code block inside blockquote:
>
> Quote
Double `>>>` inside code block inside blockquote:
> Quote
>
> ```
......@@ -63,7 +56,6 @@ Double `>>>` inside code block inside blockquote:
>
> Quote
Single `>>>` inside HTML:
<pre>
......@@ -84,13 +76,10 @@ Double `>>>` inside HTML:
Blockquote outside HTML:
> Quote
HTML inside blockquote:
> Quote
>
> <pre>
......@@ -99,10 +88,8 @@ HTML inside blockquote:
>
> Quote
Single `>>>` inside HTML inside blockquote:
> Quote
>
> <pre>
......@@ -113,10 +100,8 @@ Single `>>>` inside HTML inside blockquote:
>
> Quote
Double `>>>` inside HTML inside blockquote:
> Quote
>
> <pre>
......@@ -128,4 +113,3 @@ Double `>>>` inside HTML inside blockquote:
> </pre>
>
> Quote
spec/fixtures/encoding/Japanese.md
Просмотр файла @ 7e02921d
+++
date = "2017-05-21T13:05:07+09:00"
title = "レイヤ"
weight = 10
+++
# レイヤ
## このチュートリアルで扱う内容
1. Redactedにおける2D開発でのレイヤの基本的な概要
2. スクリーン上のスプライトの順序付け方法
1. スクリーン上のスプライトの順序付け方法
### Redactedにおける2D開発でのレイヤの基本的な概要
2Dにおいてはz軸が存在しないため、シーン内要素の描画順を制御するためには代替となる仕組みが必要です。
Redactedでは**レイヤ**における**zIndex**属性を制御可能にすることで、この課題を解決しています。
**デフォルトでは、zIndexは0となりオブジェクトはレイヤに追加された順番に描画されます。**
レイヤにはいくつかの重要な特性があります。
* レイヤにはレイヤ化されたオブジェクトのみを含めることができます。(**3Dモデルは絶対に追加しないでください**）
* レイヤはレイヤ化されたオブジェクトです。（したがって、レイヤには他のレイヤを含めることができます)
* レイヤ化されたオブジェクトは、最大で1つのレイヤに属すことができます。
- レイヤにはレイヤ化されたオブジェクトのみを含めることができます。(**3Dモデルは絶対に追加しないでください**）
- レイヤはレイヤ化されたオブジェクトです。（したがって、レイヤには他のレイヤを含めることができます)
- レイヤ化されたオブジェクトは、最大で1つのレイヤに属すことができます。
レイヤを直接初期化することはできませんが、その派生クラスは初期化することが可能です。**Scene2D**と**コンテナ**は、**レイヤ**から派生する2つの主なオブジェクトです。すべての初期化（createContainer、instantiate、...）はレイヤ上で行われます。つまり、2Dで初期化されるすべてのオブジェクトは、zIndexプロパティを持つレイヤ化されたオブジェクトです。
......@@ -27,16 +29,18 @@ Redactedでは**レイヤ**における**zIndex**属性を制御可能にする
CSSとは異なり、zIndexはすべてのオブジェクトに対してグローバルではありません。zIndexプロパティは親レイヤに対してローカルです。詳細につきましては、コンテナチュートリアルで説明しています。 [TODO: Link]。
### スクリーン上のスプライトの順序付け方法
これまで学んだことを生かして、画面にスプライトを表示して、zIndexの設定をしてみましょう！
* まず、最初に (A,B,C)　スプライトを生成します。
* スプライトAをシーンに追加します（zIndex = 0、標準色）
* スプライトBをシーン2に追加すると、**スプライトAの上に**表示されます（zIndex = 0、赤色）
* 最後にスプライトCをシーンに追加します（青色）が、スプライトのzIndexを-1に設定すると、スプライトはAとBの後側に表示されます。
- まず、最初に (A,B,C)　スプライトを生成します。
- スプライトAをシーンに追加します（zIndex = 0、標準色）
- スプライトBをシーン2に追加すると、**スプライトAの上に**表示されます（zIndex = 0、赤色）
- 最後にスプライトCをシーンに追加します（青色）が、スプライトのzIndexを-1に設定すると、スプライトはAとBの後側に表示されます。
{{< code "static/tutorials/layers.html" >}}
### ソースコード全体
```js
{{< snippet "static/tutorials/layers.html" >}}
```
spec/frontend/fixtures/static/README.md
Просмотр файла @ 7e02921d
# Please do not add new files here!
# Please do not add new files here
Instead use a Ruby file in the fixtures root directory (`spec/frontend/fixtures/`).
spec/migrations/README.md
Просмотр файла @ 7e02921d
......@@ -91,7 +91,7 @@ Example: `describe SomeClass, :migration, schema: 20170608152748`.
### Example
This spec tests the [`lib/gitlab/background_migration/archive_legacy_traces.rb`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.6.5/lib/gitlab/background_migration/archive_legacy_traces.rb)
background migration. You can find the complete spec on
background migration. You can find the complete spec on
[`spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.6.5/spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb)
```ruby
......
vendor/Dockerfile/CONTRIBUTING.md
Просмотр файла @ 7e02921d
## Developer Certificate of Origin + License
# Developer Certificate of Origin + License
By contributing to GitLab B.V., You accept and agree to the following terms and
conditions for Your present and future Contributions submitted to GitLab B.V.
......
vendor/gitignore/Global/README.md
Просмотр файла @ 7e02921d
## Globally Useful gitignores
# Globally Useful gitignores
This directory contains globally useful gitignores,
e.g. OS-specific and editor specific.
......
Поддерживает Markdown
0% или .
You are about to add 0 people to the discussion. Proceed with caution.
Сначала завершите редактирование этого сообщения!
Пожалуйста, зарегистрируйтесь или чтобы прокомментировать