Monday, October 11, 2021

JS Promises - Execution Order and Timing

As long as I've been working with JS (just look at how old this blog is to begin getting an idea), I've continued to struggle with execution order and wanted to get it clear in my head. The following helped me do that so I wanted to share.

console.time('full execution');
console.time('code block');
function showExecutionOrder(parm) {
    console.time('outside promise');
    new Promise((resolvereject=> {
        console.time('inside promise');
        console.timeEnd('inside promise');
    }).then((data=> {
        // Lookup mdn and invoke the account sync as required
        console.log({ data });
    console.timeEnd('outside promise');
console.time('function call');
showExecutionOrder({ foo: true });
console.timeEnd('function call');
console.timeEnd('code block');
console.timeEnd('full execution');

Update: Another demonstration, in another context:

Monday, September 21, 2020

Executing Gitlab-runner locally with Docker (local runner and local code)

It's hard to prioritize writing when I have so many responsibilities AND interests, but when my battles stand to save others days or weeks of pain (or abandoning a project) and it can hilite my work (rare), I must write, right!? ;P

So far, I cannot get a runner to use my local files mounted, but I can commit locally, execute the runner locally and have it use that latest commit (not yet pushed). This is arguably better than my present approach other than having to commit (even locally) for every change.

If anyone knows how to skip Git locally all-together, I'd love to hear how!

What you wanted!

mkdir -p ./.gitlab-runner/builds \  
 docker run --name=runner-${PWD##*/} --privileged -t --rm \  
 -v /var/run/docker.sock:/var/run/docker.sock \  
 -v $PWD/.gitlab-runner/:/etc/gitlab-runner \  
 -v ${PWD}:${PWD} \  
 --workdir $PWD \  
 gitlab/gitlab-runner \  
 exec docker --builds-dir $PWD/.gitlab-runner/builds/ yourStage;  

If "yourStage" were debug and your .gitlab-ci.yml looked like the following, you should expect to see the output of the `ls` command reflecting your WORKDIR.

image: docker:git  
  - debug  
  DOCKER_DRIVER: overlay2  
  DOCKER_TLS_CERTDIR: "/certs"  
  - printf "::STARTING_BEFORE_SCRIPT\n\n";  
  - export REVISION=$(git rev-parse --short HEAD)  
  - printf "::REVISION=${REVISION}\n"  
  image: docker:19.03-dind  
  stage: debug  
   - pwd; ls -lah;  

I hope to spend time in the near future covering the experiences I've had implementing GitLab, challenges I've faced, solutions to those challenges and my hot-takes on the overall approach. For now, I hope that helped someone else because it was a long-time coming for me :)

Wednesday, September 2, 2020