manual publishing in a (GitLab) CI environment breaks because of alternative behavior when CI environment variable is set about projen HOT 9 OPEN

The release task on any kind of JsiiProject is just really bad. The proper fix is to completely get rid of this conditional behavior. I'm very strongly of the opinion now that tasks should behave the same(*) no matter where they are run.

(*) In the relevant bits. They surely can print different things and disable interactive input.

At the moment, the only work around I can offer is for you to run the steps of release directly.

from projen.

Ah now I'm with you. 😅 All good. We all know that stuff sometimes doesn't translate well I'm text form. I didn't even click that that's your username 🤦

from projen.

I had some time to rework the pipeline today, and it seems that this is working for me:

  script:
    # abort if the dist directory exists
    - "[ ! -x dist ]"
    # gitlab-ci checks out a detached HEAD, but the "publish:git" task pushes "main", so make sure the "main" ref exists
    - git fetch origin $CI_COMMIT_REF_NAME
    - git checkout $CI_COMMIT_REF_NAME
    - git branch -v # sanity check
    - pnpx projen install:ci
    - pnpx projen
    - pnpx projen bump
    - pnpx projen pre-compile
    - pnpx projen compile
    - pnpx projen post-compile
    - pnpx projen test
    - pnpx projen package-all # package has the wrong behaviour when the CI environment variable is defined (replaces dist dir)
    - pnpx projen unbump
    # push npm packages
    - echo "@myscope:registry=https://${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/" > .npmrc
    - echo "//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}" >> .npmrc
    - pnpm publish --no-git-checks dist/js/*tgz
    # push nuget packages
    - dotnet nuget add source "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text
    - dotnet nuget push "dist/dotnet/*.nupkg" --source gitlab
    - dotnet nuget push "dist/dotnet/*.snupkg" --source gitlab
    - git diff --ignore-space-at-eol --exit-code
    # standard origin does not allow pushing, needed by publish:git task
    - git remote remove origin || true
    - git remote add origin https://$CI_RELEASE_USER:$CI_RELEASE_TOKEN@$CI_SERVER_HOST/$CI_PROJECT_PATH
    - pnpx projen publish:git

• Would it be in scope for projen to generate these (gitlab-ci.yaml files) as well?
• How would one start work on supporting such a feature?

P.S.: I did need to use an escape hatch to enable NPM scoped packages, in .projenrc.ts:

// Can not yet use scoped packages because Projen only supports AWS Code Artifact for scoped packages for the time being.
//
// Error: Only AWS Code artifact scoped registry is supported for now, found https://<redacted>.dev/api/v4/projects/1/packages/npm/
// scopedPackagesOptions: [{
// 	scope: "@myscope",
// 	registryUrl: "https://<redacted>.dev/api/v4/projects/1/packages/npm/"
// }],
packageJson.addOverride("publishConfig", {
  registry: "https://<redacted>.dev/api/v4/projects/2/packages/npm/",
  scope: "@myscope",
});

from projen.

That looks great!

Would it be in scope for projen to generate these (gitlab-ci.yaml files) as well?
How would one start work on supporting such a feature?

Yes, absolutely! I think currently the implementation would be to make the Release component (and other related components) aware of the existence of GitLab and basically to a switch/if depending on which CI/CD systems are available. Most of the GitHub code seems to be in this method: https://github.com/projen/projen/blob/main/src/release/release.ts#L568

As a starting point, can you post the code snippet that is creating your GitLab file?

The end-game for this would be to find a common interface between GitHub Workflows and GitLab Pipelines, so that components like Release can use a single shared interface, and delegate the implementation details to each system. However this is not something that's currently in the works, and frankly is a bit challenging due to the lack of comparable workflow definitions for multiple systems. So having this available would actually be super helpful.

from projen.

As a starting point, can you post the code snippet that is creating your GitLab file?

rdewaele_editing_in_vim.jpg 🙃😅

I can currently offer no guarantees regarding time to work on a projen feature. I do think I can formulate a use case for my company, so it’s in the cards. I’ll look into it next week.

from projen.

rdewaele_editing_in_vim.jpg 🙃😅

???

I can currently offer no guarantees regarding time to work on a projen feature. I do think I can formulate a use case for my company, so it’s in the cards. I’ll look into it next week.

Yes of course. No worries.

from projen.

???

You were asking about the code that is generating GitLab snippet. There is no such code. The snippet was manually written by me.

from projen.

???

You were asking about the code that is generating GitLab snippet. There is no such code. The snippet was manually written by me.

Okay, but can you share the snippet? Like this was just a filename?!? I'm so confused.

from projen.

Sorry for the confusion.

The script: section above is part of the .gitlab.yaml file. I wrote this myself, as in directly by hand.
I understood your question to be about something that generated that script: section. There is no such thing, and because I wrote it by hand, I jokingly referred to a picture of me typing in vim - as in I am that generator, and a picture of me is “pasting the generator of the pipeline code”.

from projen.