Q: The uploadAmiBakingManifest failed due to startScripts can't download a needed jar. What should be done?
A: In the previous gradle run, run distTar instead to ensure every needed jar is downloaded.
Q: The uploadAmiBakingManifest failed due to compileJava can't download a needed Jar, even when distTar has been executed before. What should be done?
A: Check your snapshot settings. If cacheChangingModulesFor is set to low (or 0 seconds, which means not at all), compileJava will need to redownload snapshots. Set the snapshot cache time to 1 hour (3600 seconds). If you ever need to use latest dependencies (which might be the case for local builds or for those that already uses local cache for codebuild pipeline), you can force gradle to download latest snapshots by --refresh-dependencies flag. Use this flag on the build / distTar command, not on the release command.
Q: Jenkins pipeline failed since access to beiartf is denied. But in the Jenkinsfile, the assume_role script is already run. What is the cause?
A: There are multiple changes necessary here. First, ensure you run the assume_role in the same withCredentials block as BeiartfUtil.assumeRole(this) . It should be safe to erase the BeiartfUtil later. Second, for the gradle command that runs uploadAmiBakingManifest, please add -Daws.profile=default. Last, between the two withCredentials block, add ./gradlew :<YOUR_MODULE>:distTar (use two levels of <YOUR_MODULE> in monorepo). The end result looks like this:
stage("publish") {
withCredentials([
[
$class : 'AmazonWebServicesCredentialsBinding',
accessKeyVariable: "AWS_ACCESS_KEY_ID",
credentialsId : 'tvlk-dev-user-jenkins',
secretKeyVariable: "AWS_SECRET_ACCESS_KEY"
]
]) {
BeiartfUtil.assumeRole(this)
sh "./scripts/assume_role.sh -r arn:aws:iam::517530806209:role/external/BeiartfWriter_jenkins"
}
sh "./gradlew :<YOUR_MODULE>:distTar"
withCredentials([
[
$class : 'AmazonWebServicesCredentialsBinding',
accessKeyVariable: "AWS_ACCESS_KEY_ID",
credentialsId : 'traveloka-builds-credential-s3',
secretKeyVariable: "AWS_SECRET_ACCESS_KEY"
]
]) {
sh "./gradlew :<YOUR_MODULE>:uploadAmiBakingManifest -Daws.profile=default"
}
Q: I can't execute Gradle in my local computer, even though I have run assume_role. What should I do?
A: Make sure your terminal is free from these environment variables: AWS_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID, AWS_PROFILE(this is usually set for those who use gsts). If any of that are set, AWS SDK will pick those values first and gradle will execute using incorrect credential. You can set those environment variable using values output by the assume_role script, but be warned that you will have to restart IDEA every one hour that way.
Q: My aws-google-auth doesn't work. What should I do?
A: You can use Chrome browser to login to AWS through Google account, a plugin will extract your credential, see https://29022131.atlassian.net/wiki/spaces/AWS/pages/1187351474/Alternate+way+to+use+AWS+APIs+via+CLI+when+using+Google+SSO. Just make sure you copy the correct user (it should contain SAMLUser, otherwise you will get confusing errors during assume_role.sh)
Q: I don't want to use Chrome. Any other way?
A: There are alternatives to aws-google-auth, such as gsts or saml2aws. Pick one that works for you. But considering site-infra has vetted aws-google-auth as safe, that should be an extra point for aws-google-auth. You can check the github issues page for aws-google-auth.
Q: I got hit by an error when running assume_role.sh in my local laptop, saying Invalid endpoint: https://sts..amazonaws.com
A: add --region ap-southeast-1 \ to the assume-role command, before the --role-arn part. The diff in the announcement has been updated to cover this case.
Q: I got hit with an error about io.grpc:grpc-core not found even after applying every suggestion in this FAQ. What's the cause?
A: We are looking into it, but we believe the main problem is caused by io.grpc:grpc-auth declaring a dependency to io.grpc:grpc-core with the version number inside a bracket. This results in Gradle treating that number as dynamic dependency and acting strangely. For now, this is solvable by using global.lock, thanks to @handrianv for all this info. Alternatively, one can use resolutionStrategy.force in the subproject block for grpc-core to change its version to 1.13.1 (or the version found inside your lockfile) directly.
Q: I got Error while executing command: ./scripts/assume_role.sh -r arn:aws:iam::517530806209:role/BeiartfWriter_***. Reason: exit status 126. What is that?
A: Change the assume_role.sh file to be executable. Running command chmod 755 scripts/assume_role.sh and committing the change should do the trick.