Skip to content

Update readme and parameters to they match each other #17

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

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Dockerfile
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
FROM okteto/okteto:latest
FROM okteto/okteto:2.18.0
Copy link
Contributor

Choose a reason for hiding this comment

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

@jLopezbarb shall we start pinning the version for the actions?

Should we add updating the pinned version as part of the release?

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 were going to use:

  • main for latest
  • v2 for the latest v2
  • v1 for the latest v1
    If we pin it we would have to change it in every CLI release and we'll need to update the actions script

Copy link
Member Author

@rberrelleza rberrelleza Aug 10, 2023

Choose a reason for hiding this comment

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

Suggested change
FROM okteto/okteto:2.18.0
FROM okteto/okteto:latest


COPY entrypoint.sh /entrypoint.sh

Expand Down
96 changes: 70 additions & 26 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,25 @@ You can use this action to build images from an [Okteto Manifest](https://www.ok

## Inputs

### `tag`
Copy link
Contributor

Choose a reason for hiding this comment

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

The inputs where removed as "not suported" although they exist at the actions.yaml in order to preserve compatibility with older workflows

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 the inputs are for the v1 branch so it depend on how we want to organise the v1 and v2.

v1 had some tags that were retrocompatible with v2.

Copy link
Member Author

@rberrelleza rberrelleza Aug 10, 2023

Choose a reason for hiding this comment

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

all the inputs I added here are active on the latest version of the Okteto CLI. Can we add them here?


The name and (optionally) a tag to use for the impage, in the 'name:tag' format. If specified, the action will automatically push the image on a succesfull build.


### `file`

The path to the Okteto Manifest. Default `"okteto.yml"`.
Name of the Dockerfile. Default `"Dockerfile"`.
The relative path to the Okteto Manifest. Default `"okteto.yaml"`.

> You can also use this input to point to a Dockerfile. In this mode, okteto build will ignore your Okteto manifest, and directly build the image defined in the Dockerfile. Use this to build images that are not defined on your Okteto manifest.

### `path`

The execution path of the action.


### `buildargs`

A list of comma-separated build arguments.

### `global`

Expand All @@ -24,7 +39,7 @@ Only admins can push images to the global registry.

## Example usage

This example runs the context action and then builds and pushes an image.
This example sets the context, and then builds the images defined on the default `okteto.yaml` file.

```yaml
# File: .github/workflows/workflow.yml
Expand All @@ -48,33 +63,62 @@ jobs:

## Advanced usage

### Custom Certification Authorities or Self-signed certificates
### Build an image that is not defined in the manifest

You can specify a custom certificate authority or a self-signed certificate by setting the `OKTETO_CA_CERT` environment variable. When this variable is set, the action will install the certificate in the container, and then execute the action.
This example sets the context, and then builds an image that is not defined in the Okteto manifest
Copy link
Contributor

Choose a reason for hiding this comment

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

@jLopezbarb do you have context on why tag was not supported anymore with 2.0 change?

Copy link
Contributor

Choose a reason for hiding this comment

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

I can't remember. I think it was because with the manifest v2 some flags were skipped so we created v1 and v2 to differentiate between them


Use this option if you're using a private Certificate Authority or a self-signed certificate in your [Okteto Enterprise](http://okteto.com/enterprise) instance. We recommend that you store the certificate as an [encrypted secret](https://docs.github.com/en/actions/reference/encrypted-secrets), and that you define the environment variable for the entire job, instead of doing it on every step.


```yaml
# File: .github/workflows/workflow.yml
on: [push]
```yaml
# File: .github/workflows/workflow.yml
on: [push]

name: example
name: example

jobs:
devflow:
runs-on: ubuntu-latest
env:
OKTETO_CA_CERT: ${{ secrets.OKTETO_CA_CERT }}
steps:
jobs:

- name: checkout
uses: actions/checkout@master

- uses: okteto/context@latest
with:
token: ${{ secrets.OKTETO_TOKEN }}

devflow:
runs-on: ubuntu-latest
steps:

- uses: okteto/context@latest
with:
token: ${{ secrets.OKTETO_TOKEN }}

- name: "Build"
uses: okteto/build@latest
```
with:
tag: registry.okteto.example.com/okteto/web-deps-cache:latest
file: deps-cache.Dockerfile
path: web
```


### Custom Certification Authorities or Self-signed certificates

You can specify a custom certificate authority or a self-signed certificate by setting the `OKTETO_CA_CERT` environment variable. When this variable is set, the action will install the certificate in the container, and then execute the action.

Use this option if you're using a private Certificate Authority or a self-signed certificate in your [Okteto Enterprise](http://okteto.com/enterprise) instance. We recommend that you store the certificate as an [encrypted secret](https://docs.github.com/en/actions/reference/encrypted-secrets), and that you define the environment variable for the entire job, instead of doing it on every step.


```yaml
# File: .github/workflows/workflow.yml
on: [push]

name: example

jobs:
devflow:
runs-on: ubuntu-latest
env:
OKTETO_CA_CERT: ${{ secrets.OKTETO_CA_CERT }}
steps:

- name: checkout
uses: actions/checkout@master

- uses: okteto/context@latest
with:
token: ${{ secrets.OKTETO_TOKEN }}

- name: "Build"
uses: okteto/build@latest
```
32 changes: 25 additions & 7 deletions entrypoint.sh
Original file line number Diff line number Diff line change
@@ -1,24 +1,42 @@
#!/bin/sh
set -e

tag=$1
file=$2
path=$3
buildargs=$4
global=$5

BUILDPARAMS=""

if [ ! -z "$OKTETO_CA_CERT" ]; then
if [ -n "$OKTETO_CA_CERT" ]; then
echo "Custom certificate is provided"
echo "$OKTETO_CA_CERT" > /usr/local/share/ca-certificates/okteto_ca_cert.crt
update-ca-certificates
fi

params=$(eval echo --progress plain -f "$file")
params=""

if [ -n "$tag" ]; then
params="${params} --tag=${tag}"
fi

if [ -n "$file" ]; then
params="${params} --file=${file}"
fi

if [ "$global" = "true" ]; then
params="${params} --global"
params="${params} --global"
fi

if [ -n "$buildargs" ]; then
IFS=',' ;for i in $buildargs; do
params="${params} --build-arg=${i}"
done
fi

params=$(eval echo "$params")
if [ -n "$path" ]; then
cd "$path"
fi

echo running: okteto build $params
echo running: "okteto build $params"
okteto version
okteto build $params