The Github actions documentation on reusable workflows specifies the syntax to pass secrets from caller workflow to the called workflow using the secrets: inherit tag. However, when I copy this I get an error saying
Unexpected value 'inherit'
Does anyone know what I might be doing wrong?
Related
Context
A reusable workflow in public repos may be called by appending a reference which can be a SHA, a release tag, or a branch name, as for example:
{owner}/{repo}/.github/workflows/{filename}#{ref}
Githubs documentation states:
When a reusable workflow is triggered by a caller workflow, the github context is always associated with the caller workflow.
The problem
Since the github context is always associated with the caller workflow, the reusable workflow cannot access the reference, for example the tag v1.0.0. However, knowing the reference is important when the reusable workflow needs to checkout the repository in order to make use of composite actions.
Example
Assume that the caller workflow is being executed from within the main branch and calls the ref v1.0.0. of a reusable workflow:
name: Caller workflow
on:
workflow_dispatch:
jobs:
caller:
uses: owner/public-repo/.github/workflows/reusable-workflow.yml#v1.0.0
Here is the reusable workflow that uses a composite action:
name: reusable workflows
on:
workflow_call:
jobs:
first-job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3.1.0
with:
repository: owner/public-repo
ref: ${{ github.ref_name }}
- name: composite action
uses: ./actions/my-composite-action
In the above code snippet, ${{ github.ref_name }} is main instead of v1.0.0 because github context is always associated with the caller workflow. Therefore, the composite actions code is based on main and not on v1.0.0. However, the caller wanted v1.0.0.
Hence my question: how is the reusable workflow able to access the reference given by the caller?
Say I have CI tests running via GitHub actions. The program I test has a module that checks whether its input parameters are valid. Hence, I run a test where I intentionally provide improper input parameters, so the program catches this and exits with an error (exit 1).
Problem: I want GitHub Actions to mark this test as success. I am aware of continue-on-error: true for a run. Still, this will mark any failed run as success, no matter whether my program exits intentionally with an error due to improper input parameters (as described above), or because there is a bug in my code which then should actually return a failed CI test. So far I am manually inspecting the Actions logs but there must be an automated way to catch this.
Any ideas?
I'm trying to deploy an app to production and getting a little confused by environment and application variables and what is happening at compile time vs runtime.
In my app, I have a genserver process that requires a token to operate. So I use config/releases.exs to set the token variable at runtime:
# config/releases.exs
import Config
config :my_app, :my_token, System.fetch_env!("MY_TOKEN")
Then I have a bit of code that looks a bit like this:
defmodule MyApp.SomeService do
use SomeBehaviour, token: Application.get_env(:my_app, :my_token),
other_config: :stuff
...
end
In production the genserver process (which does some http stuff) gives me 403 errors suggesting the token isn't there. So can I clarify, is the use keyword getting evaluated at compile time (in which case the application environment doest exist yet)?
If so, what is the correct way of getting runtime environment variables in to a service like this. Is it more correct to define the config in application.ex when starting the process? eg
children = [
{MyApp.SomeService, [
token: Application.get_env(:my_app, :my_token),
other_config: :stuff
]}
...
]
Supervisor.start_link(children, opts)
I may have answered my own questions here, but would be helpful to get someone who knows what they're doing confirm and point me in the right way. Thanks
elixir has two stages: compilation and runtime, both written in Elixir itself. To clearly understand what happens when one should figure out, that everything is macro and Elixir, during compilation stage, expands these macros until everything is expanded. That AST comes to runtime.
In your example, use SomeBehaviour, foo: :bar is implicitly calling SomeBehaviour.__using__/1 macro. To expand the AST, it requires the argument (keyword list) to be expanded as well. Hence, Application.get_env(:my_app, :my_token) call happens in compile time.
There are many possibilities to move it to runtime. If you are the owner of SomeBehaviour, make it accept the pair {:my_app, :my_token} and call Application.get_env/2 somewhere from inside it.
Or, as you suggested, pass it as a parameter to children; this code belongs to function body, meaning it won’t be attempted to expand during compilation stage, but would rather be passed as AST to the resulting BEAM to be executed in runtime.
Can someone please help me understand several things?
Do I still have to register PerRequestModule to use
LifeStylePerWebRequest? I use Castle.Windsor 3.2.0.0 and it seems
everything works without this module. I definetly remember that
there was an exception before that tells me "You forget to register
this module".
What "objects tracked by release policy" really
means? I use several Components with LifeStyleTransient but when I
Resolve one I get it in "objects tracked by release policy"
property, when I Resolve others I don't get them there.
How can I check the actual objects stored inside the container (and their
number)?
1) I guess since version 3.x PerRequestModule will be automatically registered by windsor.
2) An object will be tracked by windsor only if needed(for ex if its lifestyle is Transient and it implements IDisposable interface).
3) You can run unit tests checking for handlers or manually set a debug point once you registered all components and navigate with VS viewer container object: it has a property that lists all registered components.
've written two functions in a file commit_hooks.py that I want to run before any commit is made persistent, but I can't figure out how to write my hgrc to detect them.
The function headers are:
def precommit_bad_merge(ui, repo, parent1=None, parent2=None, **kwargs):
...
def precommit_bad_branching(ui, repo, **kwargs):
...
I've tried using this "guide", but the documentation is too "man pagey" for me. The following is an outcast which doesn't work.
[hooks]
precommit = ..\..\mno2\commit_hooks.py
Update!
Rewriting the hook line to:
precommit = D:\environments\next\mno2\commit_hooks.py
make Mercurial detect the precommit hook, but it always exits with status 1 for some reason.
Set up your [hooks] section like this:
[hooks]
precommit.foo = python:D:\environments\next\mno2\commit_hooks.py:precommit_bad_merge
precommit.bar = python:D:\environments\next\mno2\commit_hooks.py:precommit_bad_branching
The syntax for the precommit line that you used is for external hooks, so it was treating your python file as a self-contained script (which I'm assuming it's not since you're using the function signatures for in-process hooks).
You may need to have the python executable in your path (I do).
For more information, see the definitive guide's section on in-process hooks; there's some useful information hidden in the comments.
The "man pagey" documentation has a section on python hook syntax:
The syntax for Python hooks is as
follows:
hookname = python:modulename.submodule.callable
hookname = python:/path/to/python/module.py:callable
Python hooks are run within the
Mercurial process. Each hook is called
with at least three keyword arguments:
a ui object (keyword ui), a repository
object (keyword repo), and a hooktype
keyword that tells what kind of hook
is used. Arguments listed as
environment variables above are passed
as keyword arguments, with no HG_
prefix, and names in lower case.
If a Python hook returns a "true"
value or raises an exception, this is
treated as a failure.