Skip to content

Add Windows PowerShell 5.1 support for local runner#452

Open
mailtobash wants to merge 1 commit intoaws:mainfrom
mailtobash:feature/windows-support
Open

Add Windows PowerShell 5.1 support for local runner#452
mailtobash wants to merge 1 commit intoaws:mainfrom
mailtobash:feature/windows-support

Conversation

@mailtobash
Copy link
Copy Markdown

Add support for powershell scripts, so these images can be run on windows machines.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

- Add build.ps1 and run.ps1 for all Airflow versions
- Add .gitattributes to enforce LF line endings on all platforms
- Fix run.ps1 to write .env before build so Docker Compose picks up
  REGION on Windows (PowerShell env vars not reliably inherited)
- Fix MWAA__CORE__API_SERVER_URL in 3.0.6 and 3.1.6 to match run.sh
- Add no-AWS-credentials support
- Ignore generated .env files in .gitignore
AWS_SESSION_TOKEN="" # Put your credentials here.

# If no real credentials are provided, use dummy values and disable CloudWatch logging
if [ -z "$AWS_ACCESS_KEY_ID" ]; then
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Taking a look at create_log_group_if_not_exists here, log group is created if $ENV_NAME above has been set.

So the practical application of this is if someone set the $ENV_NAME parameter above but forgot to set the creds here, correct? If so, a visible error from the aws logs call seems more helpful than silently disabling all logging. This way the user would at least know they forgot credentials. Silently turning off logging could lead to confusion later when they expect to see logs in CloudWatch and nothing is there.

The run.ps1 approach handles this better IMO. It sets dummy credentials but leaves logging enabled. ElasticMQ and local services don't validate creds, so everything starts fine. CloudWatch call fail gracefully container-side. And if someone actually configures $ENV_NAME expecting CloudWatch, the log group creation still fails visibly at the aws logs call, which is the right signal. Logging config stays truthful.
Whichever approach we go with, it should be applied consistently across all versions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are about to migrate 3.1.6 to 3.2.0. If that change comes out first, please migrate this to 3.2.0 instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants