Give build workflow step access to required deployment environment #2672
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Certain operations in the "Arduino IDE" GitHub Actions workflow use GitHub 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"). GitHub 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, GitHub 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.
per1234
added
topic: infrastructure
giacomocusinato
approved these changes
Apr 1, 2025
There was a problem hiding this comment.
Thanks @per1234 for the promptly fix, I completely overlooked this!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Certain operations in the "Arduino IDE" GitHub Actions workflow use GitHub 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_ARNsecret. As a security measure, this secret is defined inside a deployment environment (namedproduction). GitHub 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, GitHub 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 (#2651), and when that was done, the workflow job that checks whether the secret is defined was not configured to have access to the
productionenvironment. 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 thepublishjob which publishes nightly builds of Arduino IDE, and the "publish release" step which publishes production releases.For example, if you look at the latest
scheduleevent triggered run of the workflow, which is intended to publish the nightly build, you can see that thepublishjob was incorrectly skipped:https://github.com/arduino/arduino-ide/actions/runs/14163321599/job/39672908643
The bug is fixed by configuring the
build-type-determinationjob so that it has access to the "production" environment.Originally reported by @KurtE:
https://forum.arduino.cc/t/software-download-item-nightly-2-x-builds/1369196