I'm new to github actions and trying to automate creating a docker container when I create a release.
Ideally when I create a new release in github I want it to :
compile the typescript (package.json "build" script)
build the docker image (from existing docker file)
push it to the git hub container repository
I'm using a monorepo with multiple projects and package.json / docker files so I'll want to have a workflow for each and I'm assuming some
I have a secret called ENV_FILE which has my env variables.
Ideally when I create a release I want my docker output to reflect this version.
I've found various bits and pieces but struggling to put it all together.
Related
I have a workflow that builds a Docker image.
When the workflow runs with manual trigger/push trigger the cache works fine and I get really good performance.
When I trigger the workflow through repository dispatch (another workflow that triggers the workflow) the cache doesn't work.
I tried everything: using cache module with all storage possibilities there are, running on GitHub runner, running on self-hosted runner, using bash commands to build and push the image instead of using a module, nothing seems to work.
Did anyone come across a similar issue?
This is how build and push look at the moment (on a self hosted runner):
- name: Build Docker image
id: image_id
run: |
docker build -f Dockerfile.test --build-arg LAMBDA_NAME=sharon-test LAMBDA_HANDLER=dist/apps/test/main.handler --build-arg NPM_TOKEN=${{ secrets.NPM_TOKEN }} -t ****.dkr.ecr.us-east-2.amazonaws.com/sharon-test:latest .
- name: Push Docker image
run: |
docker push ****.dkr.ecr.us-east-2.amazonaws.com/sharon-test:latest
We are using OpenShift. I have a confusion between buildconfig file vs jenkinsfile. Do we need both of them or one is sufficient. I have seen examples where in jenkinsfile docker build is defined using buildconfig file. In some cases buildconfig file is using jenkinsfile as the build strategy. Can some one please clarify on this
BuildConfig is the base type for all builds, there are different build strategies that can be used in a build config, by running oc explain buildconfig.spec.strategy you can see them all. If you want to do a docker build you use the dockerStrategy, if you want to build from source code using source2image you specify the sourceStrategy.
Sometimes you have more complex needs than simply running a build with an output image, let's say you want to run the build, wait for that image to be deployed to some environment and then run some automated GUI tests. In this case you need a pipeline. If you want to trigger and configure this pipeline from the OpenShift Web Console you would use the jenkinsPipelineStrategy in your BuildConfig. In the OpenShift 3.x web console such BuildConfigs are presented as Pipelines and not Builds even though they are all really BuildConfigs.
Any BuildConfig with the jenkinsPipelineStrategy will be executed by the Jenkins Build Server running inside the project. That Jenkins instance could also have other pipelines that are not mapped or visible in the OpenShift Web Console, there does not need to be a BuildConfig for every Jenkinsfile if you don't see the benefit of them appearing in the OpenShift Web Console.
The difference of running builds inside a Jenkinsfile and a BuildConfig with some non-jenkinsfile-strategy is that the build is actually executed inside the jenkins build agent rather than a normal OpenShift build pod.
At our company we utilize a combination of jenkinsFile pipelines and BuildConfigs with the sourceStrategy. Instead of running builds in our Jenkinsfile pipelines directly inside the Jenkins build agent we let the pipeline call the OpenShift API and tell it to execute the BuildConfig with sourceStrategy. So basically we still use s2i for building the images but the Jenkinsfile as our CI/CD pipeline engine. You can find some examples of this at https://github.com/openshift/jenkins-client-plugin.
I have a project which is available on github. I can actually add a new Java Enterprise app based on this project and have the ImageStream available:
$ oc new-app https://github.com/ocpuser/ocpdemos.git --image-stream="openshift/wildfly:latest"
$ oc get is
NAME DOCKER REPO TAGS UPDATED
javaeedemo 172.30.1.1:5000/myproject/javaeedemo
However, what is the simplest way to create just the ImageStream (without adding a new app)? My purpose is to add the ImageStream to the internal repository so that I can use it in Openshift Operators requiring it.
Thanks
Openshfit details:
Paid Professional version.
Version Information:
Been trying to create a build from a Dockerfile in Openshift.
Its tough going.
So I tried to use the existing templates in the Cluster Console.
One of which is the Docker one. When i press "Try it" it generates a sample BuildConfig, when I try to then Create it, it gives me the error:
(i have now raised the above in the Origin upstream issue tracker)
Anyhoo...anyone know how to specify a buildConfig an image from a Dockerfile in a git repo? I would be grateful to know.
You can see the build strategies allowed for OpenShift Online on the product website: https://www.openshift.com/products/online. Dockerfile build isn't deprecated, it's just explicitly disallowed in OpenShift Online. You can build your Dockerfile locally and push it directly to the OpenShift internal registry (commands for docker login and docker push are on your cluster's About page).
However, in other environments (not OpenShift Online), you can specify a Dockerfile build as follows and providing a Git Repo with a Dockerfile contained within (located at BuildConfig.spec.source.contextDir)
strategy:
type: Docker
There are additional options that can be configured for a Dockerfile build as well, outlined in https://docs.okd.io/latest/dev_guide/builds/build_strategies.html#docker-strategy-options.
Is there a way to trigger a re-deploy when I push an image to docker hub? I used S2I to build an image, put it up on docker hub, and did a deployment from there. How can I trigger a new deployment when I push a new image to docker hub?
Perhaps there is a better way? I created a wildfly image with the changes to the standalone.xml I needed. Then I used S2I to build my local source into a runnable wildfly application image, which is what I pushed and deployed. I'm trying to get around having to go through a github repository.
I'm thinking I could create an application with the customer wildfly image that I created and use the direct from IDE option to the application, but what if I want to use the command line?
You can set a scheduled flag on the image stream to have a remote registry periodically polled. This will only work though if the OpenShift cluster has been configured globally to allow that. If using OpenShift Online I don't believe that feature is enabled.
https://docs.openshift.com/container-platform/latest/dev_guide/managing_images.html#importing-tag-and-image-metadata
If you want to avoid using a Git repository, you can use a binary input build instead. This allows you to push files direct from your local computer. This means you can compile binary artifacts locally and push them into the S2I build done by OpenShift.
https://docs.openshift.com/container-platform/latest/dev_guide/builds/build_inputs.html#binary-source