Metacello loading error when credentials are provided

[JanBliznicenko]

Hello, I am trying to make GitLab CI working for my private repository. I created .gitlab-ci.yml for testing on Pharo 10 and .smalltalk.ston with passwordEnvVar set, but I get following error loading Metacello:

MetacelloNameNotDefinedError: project group, or package named: 'FileTree' not found when used in requires: or 
includes: field of package: 'Metacello-FileTree' for version: baseline of BaselineOfMetacello

Without the passwordEnvVar it starts by loading baseline of my project and everything works (for public repo).
With the passwordEnvVar set it starts by loading the Metacello and that results in the error. No matter if the repo is public or private.

This is the full log of different (but public) repo: https://gitlab.com/JanBliznicenko/openponk/-/jobs/2933194553

This is the .gitlab-ci.yml:

image: hpiswa/smalltalkci

variables:
  REPOSITORY_NAME: 'openponk'
  PROJECT_NAME: 'openponk'
  VERSION: 'nightly'
  RUN_ID: $CI_JOB_ID

build-linux:
  stage: build
  variables:
    PLATFORM: 'linux'
  before_script: 
    - "chmod u+x .github/scripts/build-linux.sh"
  script: "smalltalkci -s 'Pharo64-10'; ./.github/scripts/build-linux.sh"
  artifacts: 
    paths:
      - $PROJECT_NAME-$PLATFORM-$VERSION.zip

And this is the .smalltalk.ston:

SmalltalkCISpec {
	#loading : [
		SCIMetacelloLoadSpec {
			#platforms : [
				#pharo
			],
			#passwordEnvVar : 'GITLAB_TOKEN',
			#repository : 'gitlab://JanBliznicenko/openponk',
			#baseline : 'OpenPonk',
			#directory : 'repository',
			#load : [ 'default' ]
		}
	],
	#testing : {
		#packages : [
			'OpenPonk*',
			'FileDialog*',
			'SynchronizedLinks*'
		]
	}
}

[fniephaus]

Could you please try to run your build locally? I'm not sure whether the problem is GitLab-specific or not.

[JanBliznicenko]

@fniephaus It seems the problem does occur on any platform (tried GitLab, GitHub and locally) when I set both respository and correct password/token (passwordEnvVar). However, I managed to make it working by just not setting the repository.

When I do not set repository, it does not try to pull it (uses local files?), therefore does not need any password/token (and probably ignores it) and runs fine.
When I do set repository and it is public or I have ssh keys, it runs fine.
When I do set repository, it is private, I do not have ssh keys and do not provide passwordEnvVar, it gets stuck (until timeout) after outputting credentials error.
When I do set repository, it is private, I do not have ssh keys and do provide passwordEnvVar, it ends with this Metacello error.

[fniephaus]

Don't you have to set #usernameEnvVar as well? I don't have any experience with private repos, maybe @LinqLover can help?

[JanBliznicenko]

This is my first attempt at private repos as well, so I might have been doing something wrong. Actually, I am not sure why can we set the repository - maybe if the .smalltalk.ston is not in the built/tested repo, but somewhere separate?

As far as I understood from glimpses in README and closed PRs here and in Metacello (especially Metacello/metacello#536 (comment) by @LinqLover), it should accept either username+password or token, and the token should be filled in the passwordEnvVar.

Looking at Metacello project, it seems the issue is that when the password/token is needed and provided, SmalltalkCI tries to update Metacello (by loading its baseline). However, in case of Pharo, the baseline is made only for Pharo 7 and older. It cannot load on any newer Pharo version (I use Pharo 10). Thus my original Metacello loading error.

[LinqLover]

As far as I understood from glimpses in README and closed PRs here and in Metacello (especially Metacello/metacello#536 (comment) by @LinqLover), it should accept either username+password or token, and the token should be filled in the passwordEnvVar.

Exactly.

So how does modern Pharo load Metacello if not through the baseline? You could dispatch updateMetacello to SmalltalkCI and override it in SmalltalkCIPharo with the new Pharo routine (and maybe restore previous behavior in SmalltalkCIPharo78), I guess ...