I'm trying to use Google Cloud Build to build multiarch images and a supporting manifest so I can run my containers on both amd64 and arm processors. I can successfully build two images, but I'm unable to generate the multiarch manifest necessary... getting errors that manifests for the images I've just generated don't exist.
Here's the stage that fails:
- name: 'gcr.io/cloud-builders/docker'
id: 'manifest'
env:
- 'DOCKER_CLI_EXPERIMENTAL=enabled'
args:
- 'manifest'
- 'create'
- 'gcr.io/$PROJECT_ID/village:$COMMIT_SHA'
- 'gcr.io/$PROJECT_ID/village:arm32v6'
- 'gcr.io/$PROJECT_ID/village:amd64'
waitFor: ['amd64', 'arm']
which produces the error:
no such manifest: gcr.io/village/village:arm32v6
Already have image (with digest): gcr.io/cloud-builders/docker
A previous step of my build results in: Step #1 - "arm": Successfully tagged gcr.io/village/village:arm32v6.
Do I somehow need to push the individual images before generating the multiarch manifests? Is it possible run continue running cloud-build commands after pushing images?
It turns out you have to push the dependencies before you can create the manifest. Adding a step like below did the trick!
- name: 'gcr.io/cloud-builders/docker'
id: 'push-arm'
args:
- 'push'
- 'gcr.io/$PROJECT_ID/village:arm32v6'
waitFor: ['arm']
I ended up documenting the final configs here in case anyone else runs into this problem.
Related
I am trying to create an IPA in azure pipelines, but the Hey24sheep.flutter.flutter-build.FlutterBuild#0 task fails with the below error,
/Users/runner/work/1/s/ios/Runner/GeneratedPluginRegistrant.m:12:9: fatal error: module 'app_settings' not found
#import app_settings;
Parse Issue (Xcode): Module 'app_settings' not found
/Users/runner/work/1/s/ios/Runner/GeneratedPluginRegistrant.m:11:8
Encountered error while building for device.
##[error]Error: The process '/Users/runner/hostedtoolcache/Flutter/3.0.5/macos/flutter/bin/flutter' failed with exit code 1
This is the code added for the task,
- task: Hey24sheep.flutter.flutter-build.FlutterBuild#0
displayName: "iOS - build ipa"
inputs:
target: "ios"
buildFlavour: ${{ parameters.appSuffix }}
entryPoint: ${{ parameters.flavorEntryPoint }}
iosCodesign: false
Please note that this application works perfectly on the local machine(can build and create an ipa). Anything I have done wrong? I also followed deleting pod files and regenerating them (following almost all the answers posted in stackoverflow and other threads) but still no luck! Any assistance would be greatly appreciated.
While deploying to GCP using Terraform and in our YAML file we have the following section
# Deploy to Cloud Run
- id: 'deploy'
name: 'gcr.io/cloud-builders/gcloud'
waitFor: ['build-image','push-image']
entrypoint: bash
args:
- '-c'
- |
gcloud beta run services update $_SERVICE_NAME \
'--platform=$_PLATFORM' \
'--image=$_IMAGE_NAME' \
--labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID \
'--region=$_GCP_REGION' \
--tag '$_REVISION' \
We set WaitFor for all previous dependencies for testing. We are getting this error:
Starting Step #3 - "deploy"
Step #3 - "deploy": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #3 - "deploy": Deploying...
Step #3 - "deploy": Creating Revision......interrupted
Step #3 - "deploy": Deployment failed
Step #3 - "deploy": ERROR: (gcloud.beta.run.services.update) Revision my-service-ui-00007-doq is not ready.
Finished Step #3 - "deploy"
ERROR
ERROR: build step 3 "gcr.io/cloud-builders/gcloud" failed: step exited with non-zero status: 1
We have tried playing around with the command line and that is showing the same error. We tried several times, so this is not a random error.
Any idea what could cause this? Or any clue how we could investigate it?
I've experienced that if a non-ready revision has a traffic tag assigned (as can be the case when tagging the revision during e.g. deploy), subsequent deploys might fail. So best to go through the UI and remove all traffic tags from revisions which are not green. Maybe that fixes the problem. Just a guess if this could be the problem.
Christian
Remove that revision and tag from the YAML file and try again.
Removing from YAML will help because when updating traffic, "0%" traffic was being assigned to every revision specified in the traffic field. Since this revision is not ready, any operation that is assigning traffic (even though 0%) is causing this error.
I'm having trouble when I try to use the dir attribute of a step in my workflow. I have a directory like the following:
myproject/
folder/
subfolder/
And this is how my workflow looks like:
steps:
- uses: docker://alpine:3.12
dir: folder/subfolder
args: [pwd]
The above is stored in a wf.yml file, and I run it by doing:
cd myproject/
popper run -f wf.yml
But I'm getting the error:
ERROR: Schema validation failed:
- Key 'dir' was not defined. Path: '/steps/1'.
I am using Popper 2.6.0, and Docker 19.03.8
The dir feature in Popper is available in version 2.7.0+, so you will need to update to a newer version. In addition, as specified in the documentation, the path given to the dir attribute of a step has to be an absolute path. In the given example, since the folder being referenced is within the myproject/ folder, which is the one getting bind-mounted to /workspace inside the container, the workflow would look like:
steps:
- uses: docker://alpine:3.12
dir: /workspace/folder/subfolder
args: [pwd]
and the above should print /workspace/folder/subfolder.
I am using Bitrise and I have updated both my development machine and bitrise stack to Xcode 11.
When running a build, the Carthage dependencies need to be regenerated and since I am using AWS dependencies, even in my Mac book pro, they take a long time to build and they make the Bitrise build to time out.
Here there is an example on how my bitrise.yml is configured:
...
workflows:
test:
steps:
- gitlab-status:
run_if: not (enveq "BITRISE_GIT_COMMIT" "")
inputs:
- private_token: "$GITLAB_STATUS_TOKEN"
- preset_status: running
- api_base_url: https://gitlab.company.cloud/api/v4
- activate-ssh-key:
run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
- git-clone: {}
- cache-pull:
inputs:
- is_debug_mode: 'true'
- certificate-and-profile-installer: {}
- carthage:
inputs:
- verbose_log: 'yes'
- carthage_options: "--platform ios --no-use-binaries --cache-builds"
- cocoapods-install: {}
- xcode-test:
inputs:
- scheme: CompanyApp
- project_path: CompanyApp.xcworkspace
- simulator_device: iPhone 8
- xcode-test:
inputs:
- project_path: CompanyApp.xcworkspace
- simulator_device: iPhone 8
- scheme: CompanyAppUITests
- gitlab-status:
run_if: not (enveq "BITRISE_GIT_COMMIT" "")
inputs:
- private_token: "$GITLAB_STATUS_TOKEN"
- api_base_url: https://gitlab.company.cloud/api/v4
- cache-push:
is_always_run: true
inputs:
- is_debug_mode: 'true'
- deploy-to-bitrise-io: {}
...
Just in case, they are the last 2 lines from the build log
*** Building scheme "AWSLogs" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSMachineLearning" in AWSiOSSDKv2.xcodeproj
Any ideas???
The solution is to not rebuild libraries in CI, after adding them to repository and skipping build part in CI you will see huge build time decrease.
Try removing --no-use-binaries.
By selecting to not use binaries, large dependencies can't provide you with pre-compiled binaries to greatly decrease compile times. If you remove that flag you should notice that compilation speeds up.
Can any one help me?
Stuck from my side.
https://travis-ci.org/XinyueZ/mvvm-template/jobs/313586340
I can 't build (./gradlew test) it.
my yml is:
language: android
android:
components:
- tools
- platform-tools
- build-tools-27.0.2
- android-27
- add-on
- extra
licenses:
- 'android-sdk-license-.+'
jdk:
- oraclejdk8
script:
- ./gradlew :repository:testMockDebugUnitTest :repository:testProdDebugUnitTest :repository:testProdReleaseUnitTest
before_cache:
- rm -f $HOME/.gradle/caches/modules-2/modules-2.lock
cache:
directories:
- $HOME/.m2
- $HOME/.gradle/caches/
- $HOME/.gradle/wrapper/
buildToolsVersion = '27.0.2'
I have tried 27.0.1 as well, same failed.
I had one or three times successed, just 2 hours later, something went wrong.
same yml, no change.
See here
It seems Google uploaded a new version of the android-27 package and the checksum is now different and the download fails. For the moment, you need to install it yourself using the sdkmanager CLI instead. Here's what you would need to add to your .travis.yml file:
before_install:
- yes | sdkmanager "platforms;android-27"