Optimizing GH actions, to use less minutes. (WIP) #1563
Conversation
We can use `.lagoon.yml` to set up a GH deployment, that we can use to listen for in GH actions. This is an alternative to us spending a lot of GH minutes just waiting for the site to become available. As the `@todo`'s say, this needs some work, as I'm unsure how to use secrets and get around `set -e` as part of the deployment. **I'm looking for input for this :)** Ontop of that, also setting up `concurrency` rules to `ci-tests`, so if a second push is made, we cancel the old and unrelated workflow.
| # @todo - this action does nothing useful right now, but it is to show that | ||
| # the site URL is available as part of deployment_status. |
There was a problem hiding this comment.
I appreciate the comment but I suggest removing this file entirely.
As I see it we should not run tests on the deployed environment as implied in the workflow name. We do this on the corresponding environment established in CI.
| CloseEnvironment: | ||
| name: Close environment | ||
| runs-on: ubuntu-latest | ||
| if: ${{ github.event.action == 'closed' }} | ||
| permissions: | ||
| # Give the default GITHUB_TOKEN permission to close deployments. | ||
| deployments: write | ||
| steps: | ||
| - name: Generate environment data | ||
| id: environment | ||
| run: | | ||
| echo ::set-output name=id::pr-${{github.event.number}} | ||
| - name: Close environment | ||
| uses: bobheadxi/deployments@v1.5.0 | ||
| with: | ||
| step: deactivate-env | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
| env: ${{ steps.environment.outputs.id }} | ||
| debug: ${{ runner.debug && 'true' || 'false' }} |
There was a problem hiding this comment.
As I see it the current approach does not handle deactivating environments when the corresponding pull request is closed. I think it is a good idea to do so to avoid cluttering the project with obsolete environments which still show up as active.
As I see it Lagoon does not have a way to run code when closing an environment so I think it makes sense to keep this job as an alternate approach based on the fact that in practice closing a pull request will close the corresponding environment on Lagoon.
| # We only permit the integration with Lagoon to run if the user is | ||
| # authorized. This saves on resources and ensures we only spin up sites for | ||
| # legitimate contributions. | ||
| # The integration is controlled by creating synthetic events related to select | ||
| # pull-request events, and send them to Lagoon. | ||
| # | ||
| # The job expects the following secrets: | ||
| # LAGOON_WEBHOOK_URL: The url events are to be delivered to | ||
| # LAGOON_WEBHOOK_SECRET: Shared lagoon webhook secret | ||
| # | ||
| InformLagoon: | ||
| name: Send synthetic event to Lagoon | ||
| runs-on: ubuntu-latest | ||
| needs: [BranchNameLength] | ||
| steps: | ||
| - name: Send pull request event | ||
| uses: distributhor/workflow-webhook@v3 | ||
| env: | ||
| webhook_url: ${{ secrets.LAGOON_WEBHOOK_URL }} | ||
| webhook_secret: ${{ secrets.LAGOON_WEBHOOK_SECRET }} | ||
| webhook_type: 'json-extended' |
There was a problem hiding this comment.
Please reconsider deleting this job.
This is the one that informs Lagoon about changes to pull requests so without this new pull request environments will not be created.
| - run: | ||
| name: Create new GH deployment | ||
| command: | | ||
| # @TODO Where can i place the token as a secret? |
There was a problem hiding this comment.
Consider mentioning that we do not use set -e as we do not want the build process to stop if deployment handling fails.
| BranchNameLength: | ||
| name: Check branch length | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| - name: Ensure branch name length | ||
| uses: lekterable/branchlint-action@2.1.0 | ||
| if: github.ref_type == 'branch' || github.ref_type == 'pull_request' | ||
| with: | ||
| allowed: | | ||
| /^.{1,100}$/ | ||
| errorMessage: 'Branch name too long. This cannot be deployed to Lagoon.' |
There was a problem hiding this comment.
If we keep the Lagoon workflow around then I suggest moving this job back.
| # @TODO How do we run this, even if something has gone wrong? | ||
| - run: | ||
| name: Setting Deployment status | ||
| command: | | ||
| # @TODO How do we set this to 'failure', if something has gone wrong? | ||
| DEPLOYMENT_STATUS="success"; |
There was a problem hiding this comment.
Good question. Perhaps this video helps? https://docs.lagoon.sh/resources/faq/#how-can-i-check-the-status-of-a-build
You could also ask the Lagoon team on Discord.
We can use
.lagoon.ymlto set up a GH deployment, that we can use to listen for in GH actions.This is an alternative to us spending a lot of GH minutes just waiting for the site to become available.
As the
@todo's say, this needs some work, as I'm unsure how to use secrets and get aroundset -eas part of the deployment.I'm looking for input for this :)
Ontop of that, also setting up
concurrencyrules toci-tests, so if a second push is made, we cancel the old and unrelated workflow.