Workflows target docker hub by Org/Account.

[rbellamy]

Install maven & npm. Workflows target docker hub by Org/Account.

• Make workflows target docker hub by organization/account.
• Modified sample function to support different organization/account when pulling docker image. This assumes the same value in both GitHub and Docker Hub.
• Modified the names of the workflows to reflect their purpose.

WRT the installing npm or maven or any other tools, in reading through the code for the linux runner virtual environments, it seems the next logical step would be to leverage those same shell scripts. The fact that GitHub is using packer adds a wrinkle of complexity. I think that could be overcome with some jq scripting.

[myoung34]

i like all these changes except the maven and npm.

mostly because they're non-tunable by version, they install whats latest (npm) or whatever is in the upstream repo (unpredictable across OS flavors)

The better way to handle this is to use your runner to set up matrix testing for your language(s) similar to this

Point being: if you want to test different versions of npm (or node), or maven etc this will likely cause more issues than solutions.
Actually you already see the issue:

&& [[ $(lsb_release -cs) == "bionic" ]] && ( apt-get install -y nodejs && curl -L https://www.npmjs.com/install.sh | sh ) || ( apt-get install -y npm ) \

Id like to keep all the nuances out of the image where possible, which is why this makes sure docker works, you can use the shared socket to run npm/maven/etc as a docker container within this container

If you were to leave that out and run this on your self hosted node it should technically work because of docker:

name: Package

on:
  release:
    types: [created]

jobs:
  test:
    runs-on: self-hosted
    strategy:
      matrix:
        node: [ '10', '8' ]
    name: Node ${{ matrix.node }} sample
    steps:
      - uses: actions/checkout@v2
      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}
      - run: npm install
      - run: npm test

or maven/java:

name: Package

on:
  release:
    types: [created]

jobs:
  test:
    runs-on: self-hosted
    strategy:
      matrix:
        java: [ 11, 12, 13 ]
    name: Java ${{ matrix.java }} compile
    steps:
      - uses: actions/checkout@master
      - name: Setup java
        uses: actions/setup-java@v1
        with:
          java-version: ${{ matrix.java }}
      - run: mvn -f github-actions-java-maven/pom.xml clean compile

The rest those are 💯

[rbellamy]

Id like to keep all the nuances out of the image where possible, which is why this makes sure docker works, you can use the shared socket to run npm/maven/etc as a docker container within this container

I hadn't considered this point. Very interesting. And I can definitely see the value in not having to "fight" the installed tools in order to build matrix-based builds.

Where my head went was that this runner should have parity with the GitHub hosted runners, since most, if not all, actions will assume they are running in GitHub hosted runners. The downfall to diverging from the GitHub hosted runners is that builds will have to manage almost all their tool installations - and therefore will be markedly different than those workflows created for GitHub hosted runners.

All that said, I'll remove maven and npm and rebase.

[myoung34]

Nice add and thanks!