Add github action support

[sniper00]

What problem will this solve? we can use premake in github action‘s scripts, not need download premake and put it in git repository.

example:

# workflow name
name: linux-gcc

# Run this workflow every time a new commit pushed to your repository
on: [push, pull_request]

jobs:
  linux-gcc:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: set up premake and add to path
        uses: premake/setup-premake@v1
      - name: configure
        run: premake5 gmake
      - name: build
        run: make config=release

[KyrietS]

I think it's a good idea. I found this unofficial abel0b/setup-premake GH Action. I didn't tested it but it seems to work as you described it in your example.

If Premake decided to have it's own official action for installing Premake we would need to parametrize it (version can't be just simply hardcoded like in the @abel0b's solution). Some unit tests would be nice as well. I think that many projects would benefit from a GH Action like this.

[abel0b]

I also needed a Premake github action. If desired, I would transfer ownership to the Premake maintainers to start implementation of an official version.

[starkos]

The best way to get this done would be for someone to submit a PR with instructions for use. I can get any necessary steps added to our release checklist to bump version numbers, etc.

[KyrietS]

But GitHub Action should be placed in a separate repository, e.g. "setup-premake" so people can use "premake/setup-premake@v1" in their actions. See OP example.

I think it's not possible to submit PR for creating a new repo 🙂

[KyrietS]

I'm looking at this issue again and I'd like to suggest an API for premake-setup GH Action. Let's assume I have a C/C++ project configured with Premake5. My project has unit tests and I want to build and run them in my GitHub Action. I could do it in two ways:

Option 1

Use setup-premake to download Premake and add it to the $PATH.

steps:
  - name: Setup Premake
    uses: premake/setup-premake@v1
    with:
      version: 5.0.0-alpha16
  - name: Generate project with tests
    run: premake5 gmake2
  - name: Build tests
    run: make config=release tests
  - name: Run tests
    run: |
      cd build/tests
      ./test_binary

Option 2

Use setup-premake to generate project with the given action

steps:
  - name: Generate project with tests
    uses: premake/setup-premake@v1
    with:
      version: 5.0.0-alpha16
      action: gmake2
      options: --verbose --cc=clang
  - name: Build tests
    run: make config=release tests
  - name: Run tests
    run: |
      cd build/tests
      ./test_binary

action and options would be optional.

With version: 5.0.0-alpha16 we would rely heavily on the path to Premake's binary from Github Releases, eg. https://github.com/premake/premake-core/releases/download/v5.0.0-alpha16/premake-5.0.0-alpha16-linux.tar.gz

This means that Premake's binaries will always have to be under the path like this:

https://github.com/premake/premake-core/releases/download/{VERSION}/premake-{VERSION}-{OS}.{EXT}

With no exceptions.

@abel0b has already done a great job with his abel0b/setup-premake. But some changes are required before we ship "official" version:

• Use @vercel/ncc instead of pushing node_modules. Most popular GH Actions use ncc now. (link)
• Add input arguments for version, action, options and args to setup-premake (see my examples above). No validation is required here as Premake will print an error by itself when invalid action is provided.
• Add simple tests for all Premake's versions that are supported by setup-premake. Test would simply do:
  • donwload {VERSION} of Premake
  • compare premake5 --version with {VERSION} And this test would be a scheduled GitHub Action run once a day.

Maintenance cost

Minimal. Changes to Premake will never break setup-premake (the only exception is when you publish a binary under the unusual path)

Suggestions or comments are always welcome 🙃

[starkos]

This sounds like a good approach to me? I imagine lots of things would break if GitHub changed the release file URIs so I'm not too concerned about relying on that, and I can't think of any reason why we'd change our release file name convention, which we've been using longer than I can remember.

[abel0b]

Good ideas. I tend to have a personal preference for option 1, preferring to write explicit premake commands. If option 2 is chosen I would find useful to have premake in the path also.

[Jarod42]

With option1, it is easy to use extra premake modules. Not sure how to do it with option2.

[eariassoto]

I created the GitHub Action eariassoto/setup-premake following @KyrietS requirements. It implements idea "Option 2", so you only need to setup the input and premake will run as part of the action.

The action uses vercel/ncc to handle dependencies, and it has a workflow to test the Action on every push and PR.

The action has by default version the latest release. I set it as v5.0.0-beta1, but I also created a schedule workflow that checks once a week for a new release tag in premake/premake-coreto update the default value and the documentation.

I am happy to accept suggestions and changes. I made it to use it in my personal projects, but I want to make it suitable for everyone.

[Jarod42]

@eariassoto: How do you (plan to) handle extra modules? (That doesn't fit my needs anyway as I run premake in a script (multiple projects)).

[eariassoto]

Hi @Jarod42, I wouldn't add an extra API to the action to handle modules. The users can add steps to the job to get the modules (downloading the release file, cloning submodules, etc) in the workflow's workspace, and use the --scripts premake option.

I was thinking on adding more advanced examples to the Action's documentation, so as to showcase possible use cases for automated Premake Workflows.