• Piotr Krzemiński

    Piotr Krzemiński

    6 months ago
    anyone interested in being able to run any Kotlin code within a GH Actions step? Like:
    runKotlin {
                println("Hello from action logic!")
                File("output-first.txt").writeText("Written from first Kotlin logic")
            }
    Piotr Krzemiński
    Big Chungus
    +1
    34 replies
    Copy to Clipboard
  • Piotr Krzemiński

    Piotr Krzemiński

    5 months ago
  • Nikky

    Nikky

    5 months ago
    with kotlin 1.6.20 i can finally do this..
    sourceFile = __FILE__.toPath(),
        targetFile = __FILE__.resolveSibling(
            __FILE__.name.substringBeforeLast(".main.kts") + ".yml"
        ).toPath(),
    sadly this does not quite work out of the box.. working on a fix.. adding a parameter
    rootDirectory
    (sounds clunky.. name suggestions?) which is used to generate paths relative to
    rootDIrectory
    so that will continues to work from whatever directory you invoke it .. TL;DR the idea run script button should work with that change.. a default setup with the scripts and yml files in
    .github/workflows/
    might look like so..
    sourceFile = __FILE__.toPath(),
    targetFile = __FILE__.toPath().resolveSibling(
        __FILE__.name.substringBeforeLast(".main.kts") + ".yml"
    ),
    rootDirectory = __FILE__.toPath().absolute().parent.parent.parent,
    PS: i wish we could bake this logic into the library.. but
    __FILE__
    is a magic constant that only exists in
    main.kts
    scripts..
    Nikky
    Piotr Krzemiński
    6 replies
    Copy to Clipboard
  • Piotr Krzemiński

    Piotr Krzemiński

    3 months ago
  • jmfayard

    jmfayard

    3 months ago
    github-actions-kotlin-dsl resumed in one image 🙂
    jmfayard
    Piotr Krzemiński
    +1
    4 replies
    Copy to Clipboard
  • Piotr Krzemiński

    Piotr Krzemiński

    3 months ago
    @Vampire thanks a lot for your feedback! just noticed the issues you've created. Are you working on introducing the DSL in your project, or just playing around for fun?
    Piotr Krzemiński
    v
    13 replies
    Copy to Clipboard
  • Piotr Krzemiński

    Piotr Krzemiński

    3 months ago
    FYI: [#302] Create a tool for providing typings for action inputs and outputs - please see the discussion, especially if you're an action owner
  • Piotr Krzemiński

    Piotr Krzemiński

    3 months ago
    v0.20.0 released!
  • s

    Starr

    3 months ago
    Hi! I recently heard of this project, and it looks really cool! A while ago I wrote https://github.com/Starlight220/ActionsKtLib: a small library for writing (Docker-based) GH Actions in Kotlin. I think there might be room for some integrations or something, and I'm open to cooperation!
    s
    Piotr Krzemiński
    +1
    18 replies
    Copy to Clipboard
  • v

    Vampire

    3 months ago
    @Piotr Krzemiński another suggestion for the typing validation action. I've seen you have a dedicated
    verbose
    input to print debug information. This is rather unusal and unhandy as you have to edit the workflow definition to leverage it. I'd suggest you instead remove the input and use the standard approach to react to the
    ACTIONS_STEP_DEBUG
    secret being set to
    true
    . Or at least make the default value for that input depending on the standard way. So the consumer can just decide at runtime whether the run should be with or without debug logging and iirc GHA now even has a
    rerun with debug logging
    option that does it automatically without the need to manually change the secrets on the repository. Here how
    @actions/core
    does it: For determining whether debug is enabled to influence some behavior (for example my wsl start scripts enable echoing if it is set)
    /**
     * Gets whether Actions Step Debug is on or not
     */
    export function isDebug(): boolean {
      return process.env['RUNNER_DEBUG'] === '1'
    }
    For outputting debug logs (basically printing
    ::debug::The debug message
    ):
    /**
     * Writes debug message to user log
     * @param message debug message
     */
    export function debug(message: string): void {
      issueCommand('debug', {}, message)
    }
    
    /**
     * Commands
     *
     * Command Format:
     *   ::name key=value,key=value::message
     *
     * Examples:
     *   ::warning::This is the message
     *   ::set-env name=MY_VAR::some value
     */
    export function issueCommand(
      command: string,
      properties: CommandProperties,
      message: any
    ): void {
      const cmd = new Command(command, properties, message)
      process.stdout.write(cmd.toString() + os.EOL)
    }
    So in your case you probably wouldn't even need the
    isDebug
    logic, but simply prefixing your messages with
    ::debug::
    should already be enough.
    v
    1 replies
    Copy to Clipboard