Optimizing GH actions, to use less minutes. (WIP) #1563
Conversation
| # @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.
.github/workflows/lagoon.yml
Outdated
| 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/[email protected] | ||
| 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.
.github/workflows/lagoon.yml
Outdated
| # 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.
.lagoon.yml
Outdated
| - 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.
.github/workflows/ci-tests.yml
Outdated
| BranchNameLength: | ||
| name: Check branch length | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| - name: Ensure branch name length | ||
| uses: lekterable/[email protected] | ||
| 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.
.lagoon.yml
Outdated
| # @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.
rasben
force-pushed
the
optimize-gh-actions
branch
5 times, most recently
from
b54d954
to
55449a8
Compare
rasben
force-pushed
the
optimize-gh-actions
branch
3 times, most recently
from
bf8d8f6
to
3d7bc76
Compare
rasben
force-pushed
the
optimize-gh-actions
branch
7 times, most recently
from
7103aed
to
3d014a1
Compare
rasben
force-pushed
the
optimize-gh-actions
branch
from
3d014a1
to
181dcb8
Compare
dpl-platform-bot
temporarily deployed
to
e4bb82a64adf32dd9699636b572383cff1a5e20d
rasben
force-pushed
the
optimize-gh-actions
branch
from
181dcb8
to
ff81345
Compare
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.
rasben
force-pushed
the
optimize-gh-actions
branch
from
ff81345
to
8a876ab
Compare
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.