Skip to content

Commit

Permalink
Merge pull request #3 from yieldmo/upstream-sync
Browse files Browse the repository at this point in the history
Upstream sync
  • Loading branch information
Elber Carneiro authored Jul 30, 2019
2 parents 889e5f0 + 147c1a0 commit 8729d7c
Show file tree
Hide file tree
Showing 823 changed files with 143,237 additions and 24,981 deletions.
8 changes: 0 additions & 8 deletions .babelrc

This file was deleted.

34 changes: 34 additions & 0 deletions .babelrc.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@

let path = require('path');

function useLocal(module) {
return require.resolve(module, {
paths: [
__dirname
]
})
}

module.exports = {
"presets": [
[
useLocal('@babel/preset-env'),
{
"targets": {
"browsers": [
"chrome >= 61",
"safari >=8",
"edge >= 14",
"ff >= 57",
"ie >= 10",
"ios >= 8"
]
}
}
]
],
"plugins": [
path.resolve(__dirname, './plugins/pbjsGlobals.js'),
useLocal('babel-plugin-transform-object-assign')
]
};
50 changes: 50 additions & 0 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
build:
docker:
# specify the version you desire here
- image: circleci/node:7.10

# Specify service dependencies here if necessary
# CircleCI maintains a library of pre-built images
# documented at https://circleci.com/docs/2.0/circleci-images/
# - image: circleci/mongo:3.4.4

working_directory: ~/Prebid.js

steps:
- checkout

# Download and cache dependencies
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
# fallback to using the latest cache if no exact match is found
- v1-dependencies-

- run: npm install

- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}

- run: sudo npm install -g gulp-cli
# Download and run BrowserStack local
- run:
name : Download BrowserStack Local binary and start it.
command : |
# Download the browserstack binary file
wget "https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip"
# Unzip it
unzip BrowserStackLocal-linux-x64.zip
# Run the file with user's access key
./BrowserStackLocal ${BROWSERSTACK_ACCESS_KEY} &
# run tests!
- run:
name: BrowserStack testing
command: gulp test --browserstack --nolintfix
47 changes: 42 additions & 5 deletions .eslintrc.js
Original file line number Diff line number Diff line change
@@ -1,9 +1,29 @@

const sharedWhiteList = [
"core-js/library/fn/array/find", // no ie11
"core-js/library/fn/array/includes", // no ie11
"core-js/library/fn/set", // ie11 supports Set but not Set#values
"core-js/library/fn/string/includes", // no ie11
"core-js/library/fn/number/is-integer", // no ie11,
"core-js/library/fn/array/from" // no ie11
];

module.exports = {
"env": {
"browser": true,
"commonjs": true
},
"settings": {
"import/resolver": {
"node": {
"moduleDirectory": ["node_modules", "./"]
}
}
},
"extends": "standard",
"plugins": [
"prebid"
],
"globals": {
"$$PREBID_GLOBAL$$": false
},
Expand All @@ -19,14 +39,31 @@ module.exports = {
// Violations of these styles should be fixed, and the exceptions removed over time.
//
// See Issue #1111.
"camelcase": "off",
"eqeqeq": "off",
"no-control-regex": "off",
"no-return-assign": "off",
"no-throw-literal": "off",
"no-undef": "off",
"no-use-before-define": "off",
"no-useless-escape": "off",
"standard/no-callback-literal": "off",
}
},
"overrides": [{
"files": "modules/**/*.js",
"rules": {
"prebid/validate-imports": ["error", [
...sharedWhiteList,
"jsencrypt",
"crypto-js"
]]
}
}, {
"files": "src/**/*.js",
"rules": {
"prebid/validate-imports": ["error", [
...sharedWhiteList,
"fun-hooks/no-eval",
"just-clone",
"dlv",
"dset"
]]
}
}]
};
20 changes: 20 additions & 0 deletions .github/stale.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# Number of days of inactivity before an issue becomes stale
daysUntilStale: 14
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 7
# Issues with these labels will never be considered stale
exemptLabels:
- pinned
- security
- bug
- feature
- on hold
# Label to use when marking an issue as stale
staleLabel: stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: >
This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: false
19 changes: 0 additions & 19 deletions .travis.yml

This file was deleted.

11 changes: 4 additions & 7 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ commit your changes, and [open a pull request](https://help.github.com/articles/
master branch.

Pull requests must have 80% code coverage before beign considered for merge.
Additional details about the process can be found [here](./pr_review.md).
Additional details about the process can be found [here](./PR_REVIEW.md).

## Issues
[prebid.org](http://prebid.org/) contains documentation that may help answer questions you have about using Prebid.js.
Expand Down Expand Up @@ -48,17 +48,14 @@ When you are adding code to Prebid.js, or modifying code that isn't covered by a
- _Assert_: check that the expected results have occurred
- e.g., use Chai assertions to check that the expected output is equal to the actual output
- Test the public interface, not the internal implementation
- If using global `pbjs` data structures in your test, take care to not completely overwrite them with your own data as that may affect other tests relying on those structures, e.g.:
- **OK**: `pbjs._bidsRequested.push(bidderRequestObject);`
- **NOT OK**: `pbjs._bidsRequested = [bidderRequestObject];`
- If you need to check `adloader.loadScript` in a test, use a `stub` rather than a `spy`. `spy`s trigger a network call which can result in a `script error` and cause unrelated unit tests to fail. `stub`s will let you gather information about the `adloader.loadScript` call without affecting external resources
- When writing tests you may use ES2015 syntax if desired

### Test Examples
Prebid.js already has many tests. Read them to see how Prebid.js is tested, and for inspiration:

- Look in `test/spec` and its subdirectories
- Tests for bidder adaptors are located in `test/spec/adapters`
- Tests for bidder adaptors are located in `test/spec/modules`

A test module might have the following general structure:

Expand All @@ -67,8 +64,8 @@ A test module might have the following general structure:
import { expect } from 'chai'; // may prefer 'assert' in place of 'expect'
import adapter from 'src/adapters/<adapter>';

describe('<Adapter>', () => {
it('<description of unit or feature being tested>', () => {
describe('<Adapter>', function () {
it('<description of unit or feature being tested>', function () {
// Arrange - set up preconditions and inputs
// Act - call or act on the code under test
// Assert - use chai to check that expected results have occurred
Expand Down
25 changes: 25 additions & 0 deletions PREBID_VERSIONING_DEPRECATION.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Prebid versioning and deprecation policy

## Goals
Provide clear definitions and policy around versioning and breaking changes to APIs that are both publisher and demand partner facing.

- Limit the number of breaking changes.
- Ensure significant time for updates for breaking changes so that publisher or demand partners do not break.
- Provide a path to deprecation and reduce technical debt and increase security.
- Major versions should not be changed more than once per 30 days.

## Versioning

Follow semantic versioning so that all breaking changes occur within a major release. A breaking change includes both demand partner internal APIs* and publisher facing APIs (global APIs).

*Demand partner APIs may be excluded from breaking change policy at the core teams discretion if the changes are made so to be transparent to the bidders (such as internal refactoring).

## Deprecation process

- Open an issue with an "intent to implement" and "API impact" labels.
- Allow 2 weeks for discussion.
- Announce breaking change to the mailing list (TBD needs to be created).
- At least 2 core members needs to provide explicit approval for the deprecation.
- Open a PR against current master for console warning for possible breakage.
- Support the previous major version for a minimum of 30 days.
- Coordinate with the core team to ensure clean merging into feature branch if applicable (future major version branch).
14 changes: 11 additions & 3 deletions PR_REVIEW.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,16 @@ For modules and core platform updates, the initial reviewer should request an ad
- Review for obvious errors or bad coding practice / use best judgement here.
- If the change is a new feature / change to core prebid.js - review the change with a Tech Lead on the project and make sure they agree with the nature of change.
- If the change results in needing updates to docs (such as public API change, module interface etc), add a label for "needs docs" and inform the submitter they must submit a docs PR to update the appropriate area of Prebid.org **before the PR can merge**. Help them with finding where the docs are located on prebid.org if needed.
- Below are some examples of bidder specific updates that should require docs update (in their dev-docs/bidders/bidder.md file):
- Add support for GDPR consentManagement module > add `gdpr_supported: true`
- Add support for userId module > add `userId: pubCommon, digitrust, newProviderHere`
- Add support for video and/or native mediaTypes > add `media_types: video, native`
- Add support for COPPA > add `coppa_supported: true`
- If all above is good, add a `LGTM` comment and request 1 additional core member to review.
- Once there is 2 `LGTM` on the PR, merge to master
- Ask the submitter to add a PR for documentation if applicable.
- Add a line into the `draft release` notes for this submission. If no draft release is available, create one using [this template]( https://gist.github.com/mkendall07/c3af6f4691bed8a46738b3675cb5a479)
- Add a line into the [draft release](https://github.com/prebid/Prebid.js/releases) notes for this submission. If no draft release is available, create one using [this template]( https://gist.github.com/mkendall07/c3af6f4691bed8a46738b3675cb5a479)
- Add the PR to the appropriate project board (I.E. 1.23.0 Release) for the week, [see](https://github.com/prebid/Prebid.js/projects)

### New Adapter or updates to adapter process
- Follow steps above for general review process. In addition, please verify the following:
Expand All @@ -33,13 +39,15 @@ For modules and core platform updates, the initial reviewer should request an ad
- All user-sync (aka pixel) activity must be registered via the provided functions
- Adapters may not use the $$PREBID_GLOBAL$$ variable
- All adapters must support the creation of multiple concurrent instances. This means, for example, that adapters cannot rely on mutable global variables.
- Adapters may not globally override or default the standard ad server targeting values: hb_adid, hb_bidder, hb_pb, hb_deal, or hb_size, hb_source, hb_format.
- After a new adapter is approved, let the submitter know they may open a PR in the [headerbid-expert repository](https://github.com/prebid/headerbid-expert) to have their adapter recognized by the [Headerbid Expert extension](https://chrome.google.com/webstore/detail/headerbid-expert/cgfkddgbnfplidghapbbnngaogeldmop). The PR should be to the [bidder patterns file](https://github.com/prebid/headerbid-expert/blob/master/bidderPatterns.js), adding an entry with their adapter's name and the url the adapter uses to send and receive bid responses.

## Ticket Coordinator

Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. That person should:
- Review issues and PRs at least once per weekday for new items.
- Review issues and PRs at least once per weekday for new items. Encourage a 48 "SLA" on PRs/issues assigned. Aim for touchpoint once every 48/hours.
- For PRs: assign PRs to individuals on the PR review list. Try to be equitable -- not all PRs are created equally. Use the "Assigned" field and add the "Needs Review" label.
- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed.
- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed. Please add labels as appropriate (I.E. bug, question, backlog etc).
- Issues that are questions or troubleshooting requests may be closed if the originator doesn't respond within a week to requests for confirmation or details.
- Issues that are bug reports should be left open and assigned to someone in PR rotation to confirm or deny the bug status.
- It's polite to check with others before assigning them large tasks.
Expand Down
Loading

0 comments on commit 8729d7c

Please sign in to comment.