Give build workflow step access to required deployment environment (#2672)

per1234 · web-flow · commit 9b15695c60e0 · 2025-04-01T16:27:06.000+09:00
* Trim trailing whitespace in build workflow

* Give build workflow step access to required deployment environment

Certain operations in the "Arduino IDE"  Actions workflow use  Actions "secrets" which are defined in the
repository's administrative settings.

These secrets will typically not be defined when the workflow is run in a fork. However, the workflow's base
functionality, the automated building of the application, does not require secrets. Since that base functionality alone
is very useful to contributors (either to validate relevant changes to the application and infrastructure, or to
generate tester builds) who are performing development work in a fork. For this reason, the workflow is configured to
only perform the secret-dependent operations when the required secrets have been defined in the repository settings.

One such operation is publishing the generated builds to Amazon S3, which Arduino uses to host files for distribution.
This operation depends on the "AWS_ROLE_ARN" secret. As a security measure, this secret is defined inside a deployment
environment (named "production").  Actions workflow jobs can only use secrets from deployment environments which
they have been explicitly configured to have access to.

At the time the workflow was originally developed,  did not have the deployment environment feature, and so the
workflow was not configured to use environments. The switch to using a deployment environment for this secret was made
only recently, and when that was done, the workflow job that checks whether the secret is defined was not configured to
have access to the "production" environment. This caused the workflow to think it was running in a context where that
secret is not defined even when the secret is in fact defined. The bug caused the workflow to always spuriously skip the
"publish" job which publishes nightly builds of Arduino IDE, and the "publish release" step which publishes production
releases.

The bug is fixed by configuring the "build-type-determination" job so that it has access to the "production"
environment.
diff --git a/./workflows/build.yml b/./workflows/build.yml
@@ -172,6 +172,7 @@ jobs:
       is-nightly: ${{ steps.determination.outputs.is-nightly }}
       channel-name: ${{ steps.determination.outputs.channel-name }}
       publish-to-s3: ${{ steps.determination.outputs.publish-to-s3 }}
+    environment: production
     permissions: {}
     steps:
       - name: Determine the type of build
@@ -589,7 +590,7 @@ jobs:
 
     permissions:
       id-token: write
-      contents: read 
+      contents: read
 
     steps:
       - name: Download all job transfer artifacts
@@ -602,8 +603,8 @@ jobs:
       - name: Configure AWS Credentials for Nightly [S3]
         uses: aws-actions/configure-aws-credentials@v4
         with:
-          role-to-assume: ${{ secrets.AWS_ROLE_ARN }} 
-          aws-region: us-east-1 
+          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
+          aws-region: us-east-1
 
       - name: Publish Nightly [S3]
         run: |
@@ -661,8 +662,8 @@ jobs:
         if: needs.build-type-determination.outputs.publish-to-s3 == 'true'
         uses: aws-actions/configure-aws-credentials@v4
         with:
-          role-to-assume: ${{ secrets.AWS_ROLE_ARN }} 
-          aws-region: us-east-1 
+          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
+          aws-region: us-east-1
 
       - name: Publish Release [S3]
         if: needs.build-type-determination.outputs.publish-to-s3 == 'true'
