Merge branch 'master' into bootjdkdetet

.github/ISSUE_TEMPLATE/build-issue.md

@@ -0,0 +1,13 @@
+---
+name: 🐛 Bug Report
+about: For problems related to how the adoptopenjdk binaries are created or published
+
+---
+
+**What are you trying to do?**
+
+**Expected behaviour:**
+
+**Observed behaviour:**
+
+**Any other comments:**

.github/ISSUE_TEMPLATE/buildbreak.md

@@ -0,0 +1,11 @@
+---
+name: 😓 Build break
+about: Use this to report a broken build in jenkins
+labels: "buildbreak"
+---
+
+Thank you for reporting a broken build! Please fill in the following details:
+- **Jenkins link to the failing log:**
+- **Which platforms (OS+arch) are affected:**
+- **If you look at the historic logs, does the problem appear to be specific to one machine?**
+- **Link to any upstream project bug report (e.g. [OpenJ9](https://github.com/eclipse/openj9/issues)/[JBS](https://bugs.openjdk.java.net/browse))**

.github/ISSUE_TEMPLATE/documentation.md

@@ -0,0 +1,7 @@
+---
+name: 📚 Documentation update
+about: Request for updates to the documentation about building AdoptOpenJDK
+labels: 'documentation'
+---
+
+**Please describe what you want to be able to do that isn't documented and/or what you'd like to see in the documentation**

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,7 +1,11 @@
 ---
 name: 🚀 Feature request
 about: Suggest a new feature for this project
-
+labels: 'enhancement'
 ---
 
 Features that impact the whole project (e.g. Adding a new OpenJDK distribution)are made over at the [TSC](https://github.com/AdoptOpenJDK/TSC/).
+
+Otherwise, please describe what enhancement you would like to see in the build
+scripts:
+

.github/ISSUE_TEMPLATE/not-sure-where-to-raise-an-issue.md

@@ -4,4 +4,10 @@ about: No sure where to raise the issue?
 
 ---
 
-Take a look at our TSC repository directory [here](https://github.com/AdoptOpenJDK/TSC/#dependent-projects). If you're still not sure then join our [slack channel[(http://adoptopenjdk.net/slack) and ask on `#general`
+Unsure where to raise something? Here are some of the common places:
+- If your issue is due to the way OpenJDK is built, then this is the repository to raise it in - Describe your problem below
+- If your issue is related to our installers (as opposed to tgz/zip downloads) raise it in [openjdk-installer](https://github.com/AdoptOpenJDK/openjdk-installer/)
+- If your issue is related to and end-user visible issue with the JDK, or an underlying java bug, please raise it in [openjdk-support](https://github.com/AdoptOpenJDK/openjdk-support/issues)
+- Otherwise, take a look at our TSC repository directory [here](https://github.com/AdoptOpenJDK/TSC/#dependent-projects). If you're still not sure then join our [slack channel[(http://adoptopenjdk.net/slack) and ask on `#general`
+
+**Problem description:**

.github/workflows/build.yml

@@ -1,8 +1,6 @@
 name: Build
 
 on:
-  push:
-    branches: [ master ]
   pull_request:
     branches: [ master ]
 
@@ -11,57 +9,44 @@ jobs:
     name: Linux
     runs-on: ubuntu-latest
     container:
-      image: adoptopenjdk/centos7_build_image
+      image: ${{ matrix.image }}
     strategy:
       matrix:
-        version: [jdk8u, jdk11u, jdk15u, jdk]
+        os: [linux]
+        version: [jdk8u, jdk11u, jdk16, jdk]
         vm: [hotspot, openj9]
-
+        image: [adoptopenjdk/centos7_build_image]
+        include:
+          - os: alpine-linux
+            version: jdk16
+            vm: hotspot
+            image: adoptopenjdk/alpine3_build_image
+          - os: alpine-linux
+            version: jdk
+            vm: hotspot
+            image: adoptopenjdk/alpine3_build_image
+          - os: linux
+            version: jdk11u
+            vm: dragonwell
+            image: adoptopenjdk/centos7_build_image
     steps:
     - uses: actions/checkout@v2
-        
+
     - name: Build Linux
       run: ./build-farm/make-adopt-build-farm.sh
       env:
         JAVA_TO_BUILD: ${{ matrix.version }}
         ARCHITECTURE: x64
         VARIANT: ${{ matrix.vm }}
-        TARGET_OS: linux
+        TARGET_OS: ${{ matrix.os }}
         FILENAME: OpenJDK.tar.gz
+        # Don't set the OS as we use both linux and alpine-linux
+        PLATFORM_CONFIG_LOCATION: AdoptOpenJDK/openjdk-build/master/build-farm/platform-specific-configurations
 
-  build_macos:
-    name: macOS
-    runs-on: macos-latest
-    strategy:
-      matrix:
-        version: [jdk8u, jdk11u, jdk15u, jdk]
-        vm: [hotspot, openj9]
-
-    steps:
-    - uses: actions/checkout@v2
 
-    - name: Install Dependencies
-      run: |
-        brew install bash binutils freetype gnu-sed nasm
+    - uses: actions/upload-artifact@v2
 
-    - uses: actions/setup-java@v1
-      id: setup-java
+      name: Collect and Archive Artifacts
       with:
-        java-version: 7
-      if: matrix.version == 'jdk8u'
-
-    - name: Build macOS
-      run: |
-        export JAVA_HOME=$JAVA_HOME_11_X64
-        # Skip freetype build on jdk11+
-        if [ ${{ matrix.version }} != "jdk8u" ]; then
-          export BUILD_ARGS="--skip-freetype"
-        fi
-        ./build-farm/make-adopt-build-farm.sh
-      env:
-        JAVA_TO_BUILD: ${{ matrix.version }}
-        ARCHITECTURE: x64
-        VARIANT: ${{ matrix.vm }}
-        TARGET_OS: mac
-        FILENAME: OpenJDK.tar.gz
-        JDK7_BOOT_DIR: ${{ steps.setup-java.outputs.path }}
+        name: ${{matrix.version}}-${{matrix.os}}-${{matrix.vm}}
+        path: workspace/target/*

.github/workflows/compile.yml

@@ -1,8 +1,6 @@
 name: Compile
 
 on:
-  push:
-    branches: [ master ]
   pull_request:
     branches: [ master ]
 

.github/workflows/linter.yml

@@ -1,8 +1,6 @@
 name: Linter
 
 on:
-  push:
-    branches: [ master ]
   pull_request:
     branches: [ master ]
 

.gitignore

@@ -1,6 +1,8 @@
 .idea/
+.vscode/
 shellcheck-stable
 workspace
 pipelines/.gradle
 pipelines/gradle-cache
-pipelines/target
+pipelines/target
+**/.DS_Store

CHANGELOG.md

@@ -1,4 +1,8 @@
-# Changelog for openjdk-build scripts
+# Changelog for openjdk-build scripts (DEPRECATED)
+
+## DEPRECATION NOTES
+
+**THIS DOCUMENT IS NO LONGER POPULATED. PLEASE SEE THE [MASTER COMMIT HISTORY](https://github.com/AdoptOpenJDK/openjdk-build/commits/master) FOR A MORE UP TO DATE LOG**
 
 ## Version 1.0.0 (14th May 2018)
 

CONTRIBUTING.md

@@ -1,40 +1,49 @@
 # Contributing
-You can contribute to this project in many different ways.  **We appreciate all kinds of help, so thank you!** 
+
+You can contribute to this project in many different ways.  **We appreciate all kinds of help, so thank you!**
 
 ## Issues and Enhancements
+
 Please let us know via our [issue tracker](https://github.com/AdoptOpenJDK/openjdk-build/issues) if you find a problem, even if you don't have a fix for it.  The ideal issue report should be descriptive, and where possible include the steps we can take to reproduce the problem for ourselves.
 
 If you have a proposed fix for an issue, or an enhancement you would like to make to the code please describe it in an issue, then send us the code as a [Github pull request](https://help.github.com/articles/about-pull-requests) as described below.
 
 ## Pull requests
+
 We use GitHub's pull requests (PRs) as the primary way to accept contributions to the project.  That means we assume you have followed the usual procedure and forked the project repository, cloned your fork, created a new branch for your contribution, and pushed one or more commits to your branch.  There are many [on-line guides](https://guides.github.com/activities/forking/) that will help you with these steps.
 
 Consider whether the project documentation or tests also need updating as part of your change, and make that part of the same logical issue and PR.  Open your PR against the master branch of the project.
 
 To keep track of [the pull requests we are managing](https://github.com/AdoptOpenJDK/openjdk-build/pulls) we ask that you follow these guidelines for structuring the pull request title and comment.
 
 ### Pull request title
+
 Use a descriptive title, and if it relates to an issue in our tracker please reference which one.  If the PR is not intended to be merged you should prefix the title with "[WIP]" which indicates it is still Work In Progress.  For example, you may wish to send the PR in for an early review as you work through it.
 
 ### Pull request comment
+
 The PR comment should be formed by a one-line subject, followed by one line of white space, and one or more descriptive paragraphs, each separated by one line of white space. All of them should be finished by a dot.
 
 Where your PR fixes an issue, it should include a reference to the issue's identifier in the first line of the commit comment.  The comment should provide enough information for a reviewer to understand the changes and their relation to the rest of the code.
 
 ### Licensing and Developer certificate of origin
+
 When you submit any copyrighted material to the project via a pull request, issue tracker, or any other means, you agree to license the material under [the project's open source license](https://github.com/AdoptOpenJDK/openjdk-build/blob/master/LICENSE), and warrant that you have the legal authority to do so, whether or not you state this explicitly.
 
 We ask that you include a line similar to the following as part of your pull request comment or individual commit comments:
-```
+
+```git
 DCO 1.1 Signed-off-by: Random J Developer
 ```
+
 “DCO” stands for “Developer Certificate of Origin,” and refers to [the same text used in the Linux Kernel community](https://elinux.org/Developer_Certificate_Of_Origin).  Of course, you should replace "Random J Developer" by your own real name.
 
 By adding this simple comment, you are telling the community that you wrote the code you are contributing, or you have the right to pass on the code that you are contributing.
 
 > Tip: You can use `git commit -s ...` or configure a git `commit.template` to include the sign-off statement in your commit messages automatically.
 
 ### Source file headers
+
 All the project's source files must start with a comment, as near to the top of the file as practical, that includes a reference to [the project license](https://github.com/AdoptOpenJDK/openjdk-build/blob/master/LICENSE).  Take a look at some existing files to see how we do that, and if there are any questions just ask. In some cases, such as small, trivial files, or source files generated by tooling we don't reference the license again, but it still applies wherever the file contains copyrightable material.
 
 We don't place explicit copyright statements in the project source files.  The project comprises many distinct pieces of code, spread across numerous source files, and authored by a variety of individuals.  Managing copyright statements is unproductive and [can lead to confusion and contention around the edge cases](https://opensource.com/law/14/n2/copyright-statements-source-files).  Rather we utilize [the NOTICE file](https://github.com/AdoptOpenJDK/openjdk-build/blob/master/NOTICE) mechanism as a way to acknowledge copyright broadly where there is a valid reason to do so.
@@ -43,13 +52,16 @@ Finally, for similar reasons to avoiding individual copyright statements, we don
 
 ### Ensuring high quality
 
-If you're changing a shellscript, please make sure you run `./shellcheck.sh` before submitting your PR.
+If you're changing a shellscript, please make sure you run `./shellcheck.sh` before submitting your PR. This will also run in a GitHub check titled `Linter / Shellcheck` to ensure you comply to our coding style guidelines.
 
-After we receive your pull request the [Travis pull request builder](https://travis-ci.org/AdoptOpenJDK/openjdk-build) will test your changes and ensure they meet the coding style guidelines.  Watch for the results posted as a comment to the PR, and investigate and fix any failures.
+After we receive your pull request our [GitHub Checks](https://github.com/AdoptOpenJDK/openjdk-build/tree/master/.github/workflows) will test your changes.
+If you're making any changes to our groovy files, you'll be more interested in our [pr-tester](https://ci.adoptopenjdk.net/view/build-tester/job/build-scripts-pr-tester/job/openjdk-build-pr-tester/) jenkins job which executes a set of test pipelines in a semi-live environment. Watch for the results posted as a comment to the PR, investigate and fix any failures.
+Please see the [README.md in prTester/](pipelines/build/prTester/README.md) for more information on any of this.
 
-Fixes can simply be pushed to the same branch from which you opened your pull request.  Travis will automatically re-test when new commits are pushed and update the results.
+Fixes can simply be pushed to the same branch from which you opened your pull request. GitHub will automatically re-test when new commits are pushed and update the results.
 
 ### Reviews and merge conflicts
+
 After your PR has passed the automated testing it will be reviewed by other developers.  Comments on the changes and suggested modifications are encouraged from anybody, especially committers.  Please keep all comments focused, polite, and technical.
 
 You may consider seeking explicit feedback from a contributor who has already worked on the code being changed.
@@ -58,7 +70,6 @@ You may consider seeking explicit feedback from a contributor who has already wo
 
 Any reviewer can indicate that a change looks suitable for merging with a comment such as: “I think this patch looks good” or "this fixes the issue for me"; and we use the [LGTM](https://en.wiktionary.org/wiki/LGTM) convention for indicating the strongest level of technical sign-off on a PR.  When a committer comments with "LGTM" they specifically mean “I’ve looked at this patch thoroughly and take as much responsibility as if I wrote it myself”.
 
-Sometimes, other changes will be merged ahead of yours which cause a conflict with your pull request’s changes. The PR cannot be merged until the conflict is resolved.  As a PR author it is your responsibility to resolve the conflicts and keep the PR up to date.  To facilitiate this, try to be responsive to the review discussion rather than let days pass between replies.
+Sometimes, other changes will be merged ahead of yours which cause a conflict with your pull request’s changes. The PR cannot be merged until the conflict is resolved.  As a PR author it is your responsibility to resolve the conflicts and keep the PR up to date.  To facilitate this, try to be responsive to the review discussion rather than let days pass between replies.
 
 Again, **thank you** for contributing to the project!
-