Can a GitHub Action know its version that was specified after # character? - github-actions

In order to use a specific version of an action we use this syntax:
- name: Setup Python
uses: actions/setup-python#v1
or:
- name: Setup Python
uses: actions/setup-python#main
v1 is the name of a tag or a branch, so the code we want to use is already there.
However, I'd like to know if there is a way to get the version string inside the YAML file that defines an action.
When we create an action, we create a repository with action.yml.
Now, I'd like to retrieve this "v1" or "main" string from within the code in action.yml.
In action.yml, I'd like to have:
runs:
using: 'docker'
image: 'docker://some_url_to_image:${ the retrieved "v1" or "main" here}'
So that I could use an image that matches the version of the action.
Is this possible?

Related

SaltStack - Unable to check if file exists on minion

I am trying to check if a particular file with some extension exists on a centos host using salt stack.
create:
cmd.run:
- name: touch /tmp/filex
{% set output = salt['cmd.run']("ls /tmp/filex") %}
output:
cmd.run:
- name: "echo {{ output }}"
Even if the file exists, I am getting the error as below:
ls: cannot access /tmp/filex: No such file or directory
I see that you already accepted an answer for this that talks about jinja being rendered first. which is true. but i wanted to add to that you don't have to use cmd.run to check the file. there is a state that is built in to salt for this.
file.exists will check for a file or directories existence in a stateful way.
One of the things about salt is you should be looking for ways to get away from cmd.run when you can.
create:
file.managed:
- name: /tmp/filex
check_file:
file.exists:
- name: /tmp/filex
- require:
- file: create
In SaltStack Jinja is evaluated before YAML. The file creation will (cmd.run) be executed after Jinja. So your Jinja variable is empty because the file isn’t created, yet.
See https://docs.saltproject.io/en/latest/topics/jinja/index.html
Jinja statements such as your set output line are evaluated when the sls file is rendered, before any of the states in it are executed. It's not seeing the file because the file hasn't been created yet.
Moving the check to the state definition should fix it:
output:
cmd.run:
- name: ls /tmp/filex
# if your underlying intent is to ensure something runs only
# once the file exists, you can enforce that here
- require:
- cmd: create

What is the difference between 'name' and 'id' in Github Actions

In the github action for Google app engine deploy there is a reference to the id in a github action:
- id: Deploy
uses: google-github-actions/deploy-appengine#main
with:
credentials: ${{ secrets.GCP_SA_KEY }}
But the Github Actions examples don't refer to id, rather it refers to the name as the id:
Each job must have an id to associate with the job. The key job_id is a string and its value is a map of the job's configuration data. You must replace <job_id> with a string that is unique to the jobs object. The <job_id> must start with a letter or _ and contain only alphanumeric characters, -, or _.
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
What's the difference?
I believe you are confusing between a step definition, and a job definition.
This is a step:
steps:
- id: deploy
uses: google-github-actions/deploy-appengine#main
with:
credentials: ${{ secrets.gcp_credentials }}
as can be seen in the Usage section of the deploy-appengine repository.
The GitHub Actions workflow syntax documentation is the definitive guide - if you see something written elsewhere that is not mentioned in this guide, it is either a mistake or a misunderstanding.
As for the difference between ID and Name (both in jobs and steps):
ID is used as a reference, from other jobs or steps (for example, in jobs.<job_id>.needs).
Name is used for display purposes on GitHub.
Finally, for completeness, here are the ID/name related entries in the GitHub workflow syntax:
name: Test # <- Workflow name
jobs:
test: # <- Job ID
name: Run test suite # <- Optional Job Name
steps:
- id: checkout # <- Optional step ID
name: Checkout code # <- Optional step name

GitHub Actions - How to trim a string in a condition?

How can I trim a string in a condition in GitHub actions workflow?
In the following example, the comment can contains accidentally spaces and new lines. I want to trim the spaces in github.event.comment.body:
steps:
- name: "Check CLA signed"
if: github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA'
NOTE: Skip to the end for a better answer.
I believe GitHub Actions expressions are very limited to checking basic things in a workflow, rather than offering programming capabilities.
If you need to go the route of checking different ways of writing a message, your best option is to run a check against the string in a step:
steps:
...
- name: Check if person has accepted and signed CLA
shell: python
run: |
import sys
def check_user_accepted_and_signed(text):
"""Some complex natural language processing will go here"""
comment = '''${{ github.event.comment.body }}'''
if not check_user_accepted_and_signed(comment):
sys.exit(1) # This will abort the job
- name: Not accepted or signed
if: ${{ failure() }}
run: optionally do something if the check fails
- name: Move on if the check passed
run: ...
In the code above, you could also replace the inline Python snippet with a script call from your code base, for a cleaner code:
steps:
- uses: actions/checkout#v3
- name: Check if person has accepted and signed CLA
run: ./scripts/check-accepted-signed-cla.sh '${{ toJSON(github.event.comment.body) }}'
# Single quotes and JSON string prevents bad whitespace interpretation
Simpler is usually better
IMHO though, you'd be better off -- and safer! -- doing simple things. Here's an idea:
Set up your GitHub repository with a default pull request body containing a checkbox, for example:
Write your description.
---
- [ ] I have read the CLA and hereby sign it.
In your workflow, check for that checkbox and fail if it's not checked. Shopify/task-list-checker can be of great help here!
You can find all functions that github actions support here
I think you can use contains function for cover your case

HTML syntax highlight sublime 3 Typescript

I am using TypeScript with Sublime 3. How can I add HTML highlight in template attribute: [NOTE: I am already using Microsoft TypeScript Package]
Look how its not highlighted now:
Here's a quick fix that still makes use of your installed TypeScript package and its existing syntax highlight definition:
Open a TypeScript file (with your installed TypeScript syntax highlighting)
Select Tools > Developer > New Syntax from Typescript.tmLanguage to create a new syntax definition file based on the existing one
Find the template context (ctrl+f for string.template.ts) and add an include for 'scope:text.html.basic' to the push as indicated in the commented line below:
%YAML 1.2
---
# http://www.sublimetext.com/docs/3/syntax.html
name: TypeScript + HTML # <-- renaming is optional
# ...
template:
- match: "([_$[:alpha:]][_$[:alnum:]]*)?(`)"
captures:
1: entity.name.function.tagged-template.ts
2: punctuation.definition.string.template.begin.ts
push:
- meta_scope: string.template.ts
- match: "`"
captures:
0: punctuation.definition.string.template.end.ts
pop: true
- include: template-substitution-element
- include: string-character-escape
- include: 'scope:text.html.basic' # <-- !! only add this line !!
template-substitution-element:
# ...
optional step:
Change the name property at the beginning of the file to something like TypeScript + HTML to easily find and select it in the Syntax list later
Save the file with a .sublime-syntax file-ending
Restart Sublime Text and apply your new syntax highlighting to a typescript file:
You can read here how to achieve this:
https://forum.sublimetext.com/t/javascript-es6-template-literals-syntax-for-html/18242
Reproduced here:
Open Tools > Developer > New Syntax
Add:
%YAML1.2
---
# See http://www.sublimetext.com/docs/3/syntax.html
name: JavaScript NG
file_extensions:
- js
- ng.js
scope: source.js.ng
contexts:
main:
- match: ""
push: scope:source.js
with_prototype:
- match: '`'
push:
- meta_content_scope: text.html.basic.embedded.js
- include: 'scope:text.html.basic'
- match: '`'
pop: true
and save it has JavaScript-NG.sublime-syntax
There is also an open github issue on this:
https://github.com/sublimehq/Packages/issues/179

Ansible - Access tags at run time

How can I access the tags and skip-tags passed via command line to an ansible playbook at run time?
I am trying to achieve a with_items loop that can skip or include items based on tag/skip-tag using a when clause. This previous SO question touches on the same topic but takes a different approach.
I would evaluate the existence of a tag per iteration.
For example:
- name: Build docker images
docker_image:
name: "{{item.name}}"
path: "{{build_folder}}/dockerfiles/{{item.name}}"
dockerfile: "{{item.name}}.Dockerfile"
state: build
tag: "{{private_docker_registry}}/{{item.name}}"
when: "{{ansible_host_vars['tags'][image1]}}" is defined
with_items:
- image1
- image2
- image3
Since 2.5, ansible added some magic variables to access at runtime. Some of them is ansible_run_tags. It seems to be what you needed.
Ref: Ansible 2.5 change logs
Tags are not available at runtime. Tags define what tasks will be executed. You can use this to translate tags to facts:
- set_fact:
image1: True
tags: image1
- set_fact:
image2: True
tags: image2
- set_fact:
image3: True
tags: image3
Now you have facts corresponding to your tags and can use them in your condition:
...
when: hostvars[inventory_hostname][item] == True
with_items:
- image1
- image2
- image3
But for me this feels wrong. This is not the purpose of tags. Tags should not define what software is installed on a host. This should be defined in your group/host vars. Tags then should simply limit the play to a subset of tasks, for example to update packages, to restart services, etc.
Beside tags you could archive the same with extra-vars. This also gives you more control. If you call your playbook without any tags provided, all tasks will be executed.