Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add prerequisite check before build #8929

Merged
merged 15 commits into from
Jul 14, 2020
Merged

chore: add prerequisite check before build #8929

merged 15 commits into from
Jul 14, 2020

Conversation

ericzbeard
Copy link
Contributor

@ericzbeard ericzbeard commented Jul 7, 2020

This PR is difficult to test, since it's checking for globally installed dependencies like Java, Dotnet, etc. I'm concerned mostly about the effects on our build process, since there may be regex patterns for valid installed versions that I missed.

Hopefully it will have a positive influence on adoption for new contributors by telling them exactly what they are missing before getting deep into a build and seeing confusing error messages.

Closes Issue #8847.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@ericzbeard ericzbeard requested review from RomainMuller and eladb July 7, 2020 19:54
@ericzbeard ericzbeard changed the title feat(core) check dependencies before building chore(core) check dependencies before building Jul 7, 2020
@eladb eladb changed the title chore(core) check dependencies before building chore: add prerequisite check before build Jul 8, 2020
eladb
eladb previously requested changes Jul 8, 2020
build.sh Outdated
/bin/bash ./git-secrets-scan.sh

# Verify dependencies before starting the build
/bin/bash ./check-dependencies.sh
Copy link
Contributor

Choose a reason for hiding this comment

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

rename to check-prerequisites (we use the term "dependencies" to represent module/library dependencies)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -0,0 +1,161 @@
#!/bin/bash
Copy link
Contributor

Choose a reason for hiding this comment

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

move to scripts/ please

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

wrong_version
fi

# TODO - Should we switch to JS here instead of bash since we know node is installed?
Copy link
Contributor

Choose a reason for hiding this comment

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

bash is awesome

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with Romain that we are making it harder to eventually modify the build to be friendly to Windows developers. The more we do in TS/JS, the less duplicate code we have to write in Powershell.

wrong_version() { echo "Found $app version $app_v. Install $app >= $app_min" 1>&2; exit 1; }

check_which() {
app=$1
Copy link
Contributor

Choose a reason for hiding this comment

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

Change to locals:

Suggested change
app=$1
local app=$1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 35 to 36
app="node"
app_min="v10.13.0"
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need to store these into global variables?

This feels way more readable to me:

check_which node v10.13.0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The wrong_version function relies on them.

build.sh Outdated
/bin/bash ./git-secrets-scan.sh

# Verify dependencies before starting the build
/bin/bash ./check-dependencies.sh
Copy link
Contributor

Choose a reason for hiding this comment

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

Most of these prerequisites are only needed if you want to package (pack.sh) to multiple languages which is not what build.sh is doing. I am wondering if we should split those up to build-prereqs and pack-prereqs and only check for the packaging deps if you attempt packaging.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just saw that at least dotnet is required by the CLI unit tests...

So I think I am taking this comment back - let's just make sure the environment is fully ready.

Copy link
Contributor

@RomainMuller RomainMuller left a comment

Choose a reason for hiding this comment

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

I'd rather we stop introducing more bash and instead code this up in Javascript (or TypeScript with ts-node if we are okay with assuming npx is there -- aka a sufficiently recent node is present)

@eladb
Copy link
Contributor

eladb commented Jul 8, 2020

I'd rather we stop introducing more bash and instead code this up in Javascript (or TypeScript with ts-node if we are okay with assuming npx is there -- aka a sufficiently recent node is present)

Why? We don't have a goal or need to support non-Linux development environments. If we did, we'd have to make a major refactor to our build system. I wouldn't attempt to write this script as a portable scripts.

@ericzbeard
Copy link
Contributor Author

I'd rather we stop introducing more bash and instead code this up in Javascript (or TypeScript with ts-node if we are okay with assuming npx is there -- aka a sufficiently recent node is present)

Why? We don't have a goal or need to support non-Linux development environments. If we did, we'd have to make a major refactor to our build system. I wouldn't attempt to write this script as a portable scripts.

Doesn't it become a lot more practical once we get to monocdk? I think we should consider this as a goal for next year, if not Q4.


# Testing with this to simulate different installed apps:
# docker run -it -v ~/Source/aws-cdk:/var/cdk ubuntu bash

Copy link
Contributor

Choose a reason for hiding this comment

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

BTW, docker is also a prerequisite. It's needed for @aws-cdk/aws-s3-assets tests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a check for docker >= 19.03

@mergify mergify bot dismissed stale reviews from eladb and RomainMuller July 8, 2020 19:57

Pull request has been modified.

eladb
eladb previously requested changes Jul 9, 2020
wrong_version
fi

# [Docker 19.03.x]
Copy link
Contributor

Choose a reason for hiding this comment

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

We should also check that docker daemon is running and accessible (basically run docker ps or docker info I think)

wrong_version
fi

# [Docker 19.03.x]
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can be much more relaxed about the docker version or otherwise we will constantly have to change this. Docker hasn’t had breaking CLI changes in a couple of years to my knowledge.

I’d just check that docker is available and docker daemon is accessible.

wrong_version
fi

# [Ruby 2.5.1]
Copy link
Contributor

Choose a reason for hiding this comment

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

Please update these comments to reflect the semver description.

For example, here you are checking ^2.5.1 or >= 2.5.1 <3.0.0, right?

@mergify mergify bot dismissed eladb’s stale review July 10, 2020 19:23

Pull request has been modified.

@ericzbeard
Copy link
Contributor Author

@eladb I don't have access to the build logs to see why this is failing.

@ericzbeard
Copy link
Contributor Author

@eladb The error seems unrelated to my changes:
npm ERR! code ETARGET
npm ERR! notarget No matching version found for @aws-cdk/pipelines@1.50.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

@eladb
Copy link
Contributor

eladb commented Jul 13, 2020

@eladb The error seems unrelated to my changes:
npm ERR! code ETARGET
npm ERR! notarget No matching version found for @aws-cdk/pipelines@1.50.0.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

Probably requires diving deeper. Did you manage to build this locally?

@rix0rrr might be able to help out given this seems related to CDK pipelines...

@ericzbeard
Copy link
Contributor Author

@eladb I think it was a transient thing that happened on master around the time I pushed my last change. How can I force this to try again? Push a whitespace commit?

@eladb
Copy link
Contributor

eladb commented Jul 13, 2020

Update your branch from master

@mergify
Copy link
Contributor

mergify bot commented Jul 14, 2020

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 3ea4357
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Jul 14, 2020

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit a3008fc into aws:master Jul 14, 2020
curtiseppel pushed a commit to curtiseppel/aws-cdk that referenced this pull request Aug 11, 2020
This PR is difficult to test, since it's checking for globally installed dependencies like Java, Dotnet, etc. I'm concerned mostly about the effects on our build process, since there may be regex patterns for valid installed versions that I missed.

Hopefully it will have a positive influence on adoption for new contributors by telling them exactly what they are missing before getting deep into a build and seeing confusing error messages.

Closes Issue aws#8847.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
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.

4 participants