Deploy Git Revision

[otaviof]

As a Shipwright developer, I want to be able to deploy specific Git revision of the Build Controller repository, thus this GitHub Action can be used as part the Build Controller CI steps too.

By supporting the deployment of a specific commit, this action is also useful to test projects under active development, like triggers for example. The use-case is having a pull-request merged on the Build Controller but not yet released.

This change entails the following steps:

• Prepare the inputs to receive Git revision as well as tags
• Tweak the the installation scripts

/cc @qu1queee @adambkaplan @ricardomaraschini

[otaviof]

Thinking out loud on this subject, I'm considering using actions/checkout@v3 to load the corresponding tag/commit-id from the Shipwright Build Controller repository, and then we can use the actual release files.

Considering we may have Helm based rollouts in the future, then having the files checked out locally will help this process significantly.

We can also look at gh and other GHA specific features to bring a part of another repository to the current action workspace.

/cc @jitendar-singh

[otaviof]

Please consider the latest version (v1), now it's possible to deploy the Build Controller and the CLI using reference tag or SHA. That means we can employ this action in the Build Controller repository itself.

The following construction employs the current commit SHA, using the default environment variable ${GITHUB_SHA}:

jobs:
  use-action:
    steps:
      - uses: otaviof/setup-shipwright@v1
        with:
          shipwright-ref: ${{ env.GITHUB_SHA }}
          cli-ref: v0.10.0

We can adopt the example inside the Shipwright Build Controller repository as well as in any other location with the freedom to test against development branches, when needed.

On the CLI repository we can have the same approach, but then on cli-ref.

[otaviof]

@qu1queee let me know what's your take on this, please try and share your feedback

[qu1queee]

@otaviof ty, this is cool. I think we need to revisit the scenarios one by one where this could be used. One idea would be to promote this action into the SHP org. Depends if you would like to donate this :) . But this would be good as we already have an end user community around SHP, they might get the benefit of getting a build service for free as long as they run k8s in the git actions.

[otaviof]

Thanks for the feedback, @qu1queee!

I think we need to revisit the scenarios one by one where this could be used.

Indeed, that's the next step I think this project needs to take. As we onboard this GitHub Action on the Shipwright organization projects, we need validate it all works together and all the features needed are in place. Agreed!

One idea would be to promote this action into the SHP org. Depends if you would like to donate this :) .

I will be very proud to see this new project joining our organization, so thanks for bringing this up! 🙇

In terms of project name, I think having a "shipwright-io/setup" repository is a good name for a GitHub Actions project. For instance:

jobs:
  use-action:
    steps:
      - uses: shipwright-io/setup@v1

Please share other nice names to this initiative.

But this would be good as we already have an end user community around SHP, they might get the benefit of getting a build service for free as long as they run k8s in the git actions.

Definitely! Having Shipwright dressed as a GitHub Action project helps us to test our code-base, but also makes possible to other users to adopt Shipwright too.

P.S.: I've added this topic for the next community meeting discussion.

[otaviof]

This GitHub Action works as a decoupled actor to rollout Shipwright and dependencies, making sure the components are working as expected. Each component is checked out from the original repositories, the installation relies on the component Makefile targets directly.

When using this action inside the Shipwright organization, as well on the forked repositories, it needs to inspect the current context, in order to avoid checkout if the current repository is already the expected component. For instance, let's imagine you're working on a cli repository fork, the idea is to use the current set of changes directly to perform the CI tests against.

The changes to support this use-case are implemented in v2 release, please try it and let me know.

To use this action all you need is to add in the workflow, i.e.:

jobs:
  setup-shipwright:
    name: Shipwright
    steps:
      - uses: otaviof/setup-shipwright@v2

P.S.: Thanks @SaschaSchwarze0 for sharing the conversation with @qu1queee discussing this use-case. Thanks for bringing this up!

[otaviof]

jobs:
  setup-shipwright:
    name: Shipwright
    steps:
      - uses: shipwright-io/setup@v2