#github-actions (2022-05)

How do you overcome such an issue do we always need to map 1:1 job and node

I would only do 1:1 job and node from a security perspective

ideally the nodes cycle after each job

you’re running multiple gha runners on the same node under something like systemd?

We’re looking to try and encourage everyone to deploy the same way IMO I’d advise you to stick with allowing teams to define their own deployment strategy. I find that trying to reign every project into the same method typically means adding unnecessary steps into the process for smaller projects which means wasted time or worse people just circumventing the process because it’s annoying.

My recommendation would be to define a few workflow templates (by which I mean 2 or 3) then come up with the deployment strategy for each template, clearly define it and then have each project clearly state which template they’re using.

This provides clarity for team members to be able to contribute across multiple projects without being too restrictive.

do you use self-hosted or ubuntu-latest ?

Just ubuntu-latest. Do people commonly go for the self-hosted route?

for private repos, we use self-hosted to save on costs. we leverage self-hosted asg runners and self-hosted eks runners via summerwind action runner controller (ARC)

for public repos, we use ubuntu-latest

however, i personally haven’t noticed an issue with slow builds. Do you mean slow to start ? or slow to complete ?

Slow to complete, in my case just building a docker image. yarn install and yarn build is painfully slow. Like 30mins long before it finished CircleCI did it on 5mins

Sorry to bump so late but have you looked into yarn caching? Our heaviest projects take at most a minute after the first run

Example:

   - name: Get yarn cache directory path
        id: yarn-cache-dir-path
        run: |
          cd ${{ env.PACKAGE_NAME }}
          echo "::set-output name=dir::$(yarn cache dir)"

      - uses: actions/cache@v2
        id: yarn-cache # use this to check for `cache-hit` (`steps.yarn-cache.outputs.cache-hit != 'true'`)
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

This is more related to the install step alone btw

Yeah i did which speeds it up. But inevitably sometimes the cache does not hit and it’s so painfully slow. I feel like it’s because of the default runners that github uses