Version 29 - Upstream Update

.github/release-drafter.yml

@@ -0,0 +1,28 @@
+
+name-template: 'Prebid $RESOLVED_VERSION Release'
+tag-template: '$RESOLVED_VERSION'
+categories:
+ - title: '🚀 New Features'
+ label: 'feature'
+ - title: '🛠 Maintenance'
+ label: 'maintenance' 
+ - title: '🐛 Bug Fixes'
+ labels:
+ - 'fix'
+ - 'bugfix'
+ - 'bug' 
+change-template: '- $TITLE (#$NUMBER)'
+version-resolver:
+ major:
+ labels:
+ - 'major'
+ minor:
+ labels:
+ - 'minor'
+ patch:
+ labels:
+ - 'patch'
+ default: patch
+template: |
+ ## In This Release
+ $CHANGES

.github/workflows/release-drafter.yml

@@ -0,0 +1,18 @@
+name: Release Drafter
+
+on:
+ push:
+ # branches to consider in the event; optional, defaults to all
+ branches:
+ - master
+
+jobs:
+ update_release_draft:
+ runs-on: ubuntu-latest
+ steps:
+ # Drafts your next Release notes as Pull Requests are merged into "master"
+ - uses: release-drafter/release-drafter@v5
+ with:
+ config-name: release-drafter.yml 
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

PR_REVIEW.md

@@ -5,6 +5,17 @@ If the PR is for a standard bid adapter or a standard analytics adapter, just th
 
 For modules and core platform updates, the initial reviewer should request an additional team member to review as a sanity check. Merge should only happen when the PR has 2 `LGTM` from the core team and a documentation PR if required.
 
+### Running Tests and Verifying Integrations
+
+General gulp commands include separate commands for serving the codebase on a built in webserver, creating code coverage reports and allowing serving integration examples. The `review-start` gulp command combinese those into one command.
+
+- Run `gulp review-start`, adding the host parameter `gulp review-start --host=0.0.0.0` will bind to all IPs on the machine
+ - A page will open which provides a hub for common reviewer tools.
+ - If you need to manually acceess the tools:
+ - Navigate to build/coverage/lcov-report/index.html to view coverage
+ - Navigate to integrationExamples/gpt/hellow_world.html for basic integration testing
+ - The hello_world.html and other exampls can be edited and used as needed to verify functionality
+
 ### General PR review Process
 - All required global and bidder-adapter rules defined in the [Module Rules](https://docs.prebid.org/dev-docs/module-rules.html) must be followed. Please review these rules often - we depend on reviewers to enforce them.
 - Checkout the branch (these instructions are available on the github PR page as well).
@@ -18,7 +29,10 @@ For modules and core platform updates, the initial reviewer should request an ad
 - 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. 
 - If all above is good, add a `LGTM` comment and, if the change is in PBS-core or is an important module like the prebidServerBidAdapter, request 1 additional core member to review.
 - Once there are 2 `LGTM` on the PR, merge to master
-- 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)
+- The [draft release](https://github.com/prebid/Prebid.js/releases) notes are managed by [release drafter](https://github.com/release-drafter/release-drafter). To get the PR added to the release notes do the steps below. A github action will use that information to build the release notes.
+ - Adjust the PR Title to be appropriate for release notes
+ - Add a label for `feature`, `maintenance`, `fix`, `bugfix` or `bug` to categorize the PR
+ - Add a semver label of `major`, `minor` or `patch` to indicate the scope of change 
 
 ### Reviewing a New or Updated Bid Adapter
 Documentation they're supposed to be following is https://docs.prebid.org/dev-docs/bidder-adaptor.html

README.md

@@ -202,6 +202,11 @@ To run the unit tests:
 gulp test
 ```
 
+To run the unit tests for a perticular file (example for pubmaticBidAdapter_spec.js):
+```bash
+gulp test --file "test/spec/modules/pubmaticBidAdapter_spec.js"
+```
+
 To generate and view the code coverage reports:
 
 ```bash

RELEASE_SCHEDULE.md

@@ -1,6 +1,14 @@
 **Table of Contents**
 - [Release Schedule](#release-schedule)
 - [Release Process](#release-process)
+ - [1. Make sure that all PRs have been named and labeled properly per the PR Process](#1-make-sure-that-all-prs-have-been-named-and-labeled-properly-per-the-pr-process)
+ - [2. Make sure all browserstack tests are passing](#2-make-sure-all-browserstack-tests-are-passing)
+ - [3. Prepare Prebid Code](#3-prepare-prebid-code)
+ - [4. Verify the Release](#4-verify-the-release)
+ - [5. Create a GitHub release](#5-create-a-github-release)
+ - [6. Update coveralls _(skip for legacy)_](#6-update-coveralls-skip-for-legacy)
+ - [7. Distribute the code](#7-distribute-the-code)
+ - [8. Increment Version for Next Release](#8-increment-version-for-next-release)
 - [Beta Releases](#beta-releases)
 - [FAQs](#faqs)
 
@@ -9,7 +17,7 @@
 We aim to push a new release of Prebid.js every week on Tuesday.
 
 While the releases will be available immediately for those using direct Git access,
-it will be about a week before the Prebid Org [Download Page](http://prebid.org/download.html) will be updated. 
+it will be about a week before the Prebid Org [Download Page](http://prebid.org/download.html) will be updated.
 
 You can determine what is in a given build using the [releases page](https://github.com/prebid/Prebid.js/releases)
 
@@ -19,14 +27,20 @@ Announcements regarding releases will be made to the #headerbidding-dev channel
 
 _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for your repo, all of the following git commands will have to be modified to reference the proper remote (e.g. `upstream`)_
 
-1. Make Sure all browserstack tests are passing. On PR merge to master CircleCI will run unit tests on browserstack. Checking the last CircleCI build [here](https://circleci.com/gh/prebid/Prebid.js) for master branch will show you detailed results. 
-
- In case of failure do following, 
+### 1. Make sure that all PRs have been named and labeled properly per the [PR Process](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md#general-pr-review-process)
+ * Do this by checking the latest draft release from the [releases page](https://github.com/prebid/Prebid.js/releases) and make sure nothing appears in the first section called "In This Release". If they do, please open the PRs and add the appropriate labels.
+ * Do a quick check that all the titles/descriptions look ok, and if not, adjust the PR title.
+
+### 2. Make sure all browserstack tests are passing
+
+ On PR merge to master, CircleCI will run unit tests on browserstack. Checking the last CircleCI build [here](https://circleci.com/gh/prebid/Prebid.js) for master branch will show you detailed results.**
+
+ In case of failure do following,
  - Try to fix the failing tests.
  - If you are not able to fix tests in time. Skip the test, create issue and tag contributor.
 
- #### How to run tests in browserstack
- 
+ **How to run tests in browserstack**
+
  _Note: the following browserstack information is only relevant for debugging purposes, if you will not be debugging then it can be skipped._
 
  Set the environment variables. You may want to add these to your `~/.bashrc` for convenience.
@@ -35,40 +49,40 @@ _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for
  export BROWSERSTACK_USERNAME="my browserstack username"
  export BROWSERSTACK_ACCESS_KEY="my browserstack access key"
  ```
- 
+
  ```
  gulp test --browserstack >> prebid_test.log
- 
+
  vim prebid_test.log // Will show the test results
  ```
 
 
-2. Prepare Prebid Code
+### 3. Prepare Prebid Code
 
  Update the package.json version to become the current release. Then commit your changes.
 
  ```
- git commit -m "Prebid 1.x.x Release"
+ git commit -m "Prebid 4.x.x Release"
  git push
  ```
 
-3. Verify Release
+### 4. Verify the Release
 
  Make sure your there are no more merges to master branch. Prebid code is clean and up to date.
 
-4. Create a GitHub release
+### 5. Create a GitHub release
+
+ Edit the most recent [release notes](https://github.com/prebid/Prebid.js/releases) draft and make sure the correct version is set and the master branch is selected in the dropdown. Click `Publish release`. GitHub will create release tag.
 
- Edit the most recent [release notes](https://github.com/prebid/Prebid.js/releases) draft and make sure the correct tag is in the dropdown. Click `Publish`. GitHub will create release tag. 
-
- Pull these changes locally by running command 
+ Pull these changes locally by running command
  ```
  git pull
  git fetch --tags
- ``` 
- 
+ ```
+
  and verify the tag.
 
-5. Update coveralls _(skip for legacy)_
+### 6. Update coveralls _(skip for legacy)_
 
  We use https://coveralls.io/ to show parts of code covered by unit tests.
 
@@ -80,35 +94,23 @@ _Note: If `github.com/prebid/Prebid.js` is not configured as the git origin for
 
  Run `gulp coveralls` to update code coverage history.
 
-6. Distribute the code 
+### 7. Distribute the code
 
- _Note: do not go to step 7 until step 6 has been verified completed._
+ _Note: do not go to step 8 until step 7 has been verified completed._
 
  Reach out to any of the Appnexus folks to trigger the jenkins job.
 
- // TODO 
+ // TODO:
  Jenkins job is moving files to appnexus cdn, pushing prebid.js to npm, purging cache and sending notification to slack.
  Move all the files from Appnexus CDN to jsDelivr and create bash script to do above tasks.
 
-7. Post Release Version
-
- Update the version
- Manually edit Prebid's package.json to become "1.x.x-pre" (using the values for the next release). Then commit your changes.
+### 8. Increment Version for Next Release
+
+ Update the version by manually editing Prebid's `package.json` to become "4.x.x-pre" (using the values for the next release). Then commit your changes.
  ```
  git commit -m "Increment pre version"
  git push
  ```
-
-8. Create new release draft
-
- Go to [github releases](https://github.com/prebid/Prebid.js/releases) and add a new draft for the next version of Prebid.js with the following template:
-```
-## 🚀New Features
-
-## 🛠Maintenance
-
-## 🐛Bug Fixes
-```
 
 ## Beta Releases
 
@@ -129,11 +131,8 @@ Characteristics of a `GA` release:
 ## FAQs
 
 **1. Is there flexibility in the schedule?**
-
-If a major bug is found in the current release, a maintenance patch will be done as soon as possible.
-
-It is unlikely that we will put out a maintenance patch at the request of a given bid adapter or module owner.
+* If a major bug is found in the current release, a maintenance patch will be done as soon as possible.
+* It is unlikely that we will put out a maintenance patch at the request of a given bid adapter or module owner.
 
 **2. What Pull Requests make it into a release?**
-
-Every PR that's merged into master will be part of a release. Here are the [PR review guidelines](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md).
+* Every PR that's merged into master will be part of a release. Here are the [PR review guidelines](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md).

gulpfile.js

@@ -31,7 +31,7 @@ const execa = require('execa');
 
 var prebid = require('./package.json');
 var dateString = 'Updated : ' + (new Date()).toISOString().substring(0, 10);
-var banner = '/* <%= prebid.name %> v<%= prebid.version %>\n' + dateString + ' */\n';
+var banner = '/* <%= prebid.name %> v<%= prebid.version %>\n' + dateString + '\nModules: <%= modules %> */\n';
 var port = 9999;
 const FAKE_SERVER_HOST = argv.host ? argv.host : 'localhost';
 const FAKE_SERVER_PORT = 4444;
@@ -86,14 +86,28 @@ function viewCoverage(done) {
  connect.server({
  port: coveragePort,
  root: 'build/coverage/lcov-report',
- livereload: false
+ livereload: false,
+ debug: true
  });
  opens('http://' + mylocalhost + ':' + coveragePort);
  done();
 };
 
 viewCoverage.displayName = 'view-coverage';
 
+// View the reviewer tools page
+function viewReview(done) {
+ var mylocalhost = (argv.host) ? argv.host : 'localhost';
+ var reviewUrl = 'http://' + mylocalhost + ':' + port + '/integrationExamples/reviewerTools/index.html'; // reuse the main port from 9999
+
+ // console.log(`stdout: opening` + reviewUrl);
+
+ opens(reviewUrl);
+ done();
+};
+
+viewReview.displayName = 'view-review';
+
 // Watch Task with Live Reload
 function watch(done) {
  var mainWatcher = gulp.watch([
@@ -143,12 +157,13 @@ function makeWebpackPkg() {
 
  const analyticsSources = helpers.getAnalyticsSources();
  const moduleSources = helpers.getModulePaths(externalModules);
+ const modulesString = (externalModules.length > 0) ? externalModules.join(', ') : 'All available modules in current version.';
 
  return gulp.src([].concat(moduleSources, analyticsSources, 'src/prebid.js'))
  .pipe(helpers.nameModules(externalModules))
  .pipe(webpackStream(cloned, webpack))
  .pipe(uglify())
- .pipe(gulpif(file => file.basename === 'prebid-core.js', header(banner, { prebid: prebid })))
+ .pipe(gulpif(file => file.basename === 'prebid-core.js', header(banner, { prebid: prebid, modules: modulesString })))
  .pipe(gulp.dest('build/dist'));
 }
 
@@ -383,4 +398,8 @@ gulp.task('e2e-test', gulp.series(clean, setupE2e, gulp.parallel('build-bundle-p
 gulp.task(bundleToStdout);
 gulp.task('bundle', gulpBundle.bind(null, false)); // used for just concatenating pre-built files with no build step
 
+// build task for reviewers, runs test-coverage, serves, without watching
+gulp.task(viewReview);
+gulp.task('review-start', gulp.series(clean, lint, gulp.parallel('build-bundle-dev', watch, testCoverage), viewReview));
+
 module.exports = nodeBundle;